|
|
| Re: BIRT report engine performance test [message #194486 is a reply to message #190947] |
Tue, 10 October 2006 13:20  |
 Valery Tydykov
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
The update is here:
http://jroller.com/page/galina?entry=java_open_source_report ing_frameworks2
Java Open Source reporting frameworks. Performance Tests. Discussion
My comments on the Performance Test Results.
JFreeReport
My report and the discussion are on the Pentaho forum.
My comments:
1. Very fast reaction from the JFreeReports team. That fix eliminated the
thread contention in this particular place, and improved the mean response
time by ~10000 msecs, as Thomas predicted. Unfortunately, there are more
thread contention problems, which were hidden by the first one (typical
situation with multi-threading problems).
2. The last message in the thread is disappointing. It looks like the
remaining thread contention problems are fundamental (not easy to fix,
require major refactoring?), and the JFreeReports team is not going to fix
them. Saying that the existing performance is satisfactory is ...
disappointing. The max CPU utilization is 100%, which means that if an
application consists of forms and reports (on the same computer), the
response time for the forms will be unpredictable.
JasperReports
My report and the discussion are on the JasperForge.org Forum.
My comments:
1. So far, there was no reaction from the JasperReports team.
BIRT
My report on the eclipse.birt newsgroup; discussion on the BIRT PMC mailing
list, BIRT PMC Forum.
Bugzilla Bug 155024.
My comments:
1. So far, there was no direct response from the BIRT team. It looks like
this problem does not have a high priority for BIRT (see Bugzilla Bug
155024, and the BIRT PMC mailing list discussion).
General comments:
1. When evaluating open source frameworks, support from the framework team
is an important criteria. All three frameworks are backed by for-profit
companies, so the expectations are higher.
2. Performance is a very important framework feature. It should be on the
requirements list when the design of the framework happens - it is very
difficult to fix performance problems afterwards. Performance testing should
be a part of the development process, starting from the design and
prototyping stage. It looks like this was not the case with all three
frameworks. It looks like the results of the tests were a complete surprise
for the teams.
We were not testing any exotic use cases - we created the simplest possible
report. It should be very easy to reproduce the experiments. We
intentionally used only open source tools (Grinder, Tomcat, MySQL) in our
experiments.
We reported the exact places where the thread contention happens. It would
be much more productive to acknowledge the problems and assign somebody to
fix them, than to ask "questions about the testing methodology".
"Mauro R. Ubeda" <ubeda@delsatgroup.com> wrote in message
news:eeokb9$p2r$1@utils.eclipse.org...
>I am having same problems with simultaneous users. CPU overload turns
>system inoperable. I hope that this issue could be fixed in 2.1.1 release.
>Look on bugzilla, i had reported it days before, but it will be included on
>2.2.0 release.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=155024
> Product/Component: BIRT / Report Viewer
>
> Regards,
>
> Mauro
>
> Valery wrote:
>> http://www.jroller.com/page/galina?entry=birt_reporting_fram ework_performance_test
>>
>> Conclusions
>>
>> 1. Using the hardware and software, the MySqlData.rptdesign sample report
>> can not handle 10 simultaneous active users (CPU overload).
>>
>> We performed sample report profiling using JBuilder Thread Debugger,
>> which shows that BIRT report engine has multiple thread contention
>> problems.
>>
>> Valery
>>
>>
> m
|
|
|
Powered by
FUDForum. Page generated in 0.03254 seconds
] 
Search
Help
Register
Login
Home
