How to benchmark BIRT report performance?

Question

I have a BIRT report with performance problems: it takes approximately 5 minutes to run.

At the beginning I though the problem was the database: this report uses a quite complex SQL Server stored procedure to retrieve data. After a lot of SQL optimizations this procedure now takes ~20 seconds to run (in the management console).

However, the report itself still takes too much time (several minutes). How do I identify the other bottlenecks in BIRT report generation? Is there a way to profile the entire process? I'm running it using the www viewer (running inside Tomcat 5.5), and I don't have any Java event handlers, everything is done using standard SQL and JavaScript.

I watched the webinar "Designing High Performance BIRT Reports" 1, it has some interesting considerations but it didn't help much...

Ruddock

Answer 1

As I write this answer the question is getting close to 2 years old, so presumably you found a way around the problem. No one has offered a profiler for the entire process, so here are some ways of identifying bottle necks.

1. Start up time - About a minute can be spent here

   • running a couple reports one after the other or starting a second after the first is running can help diagnosis issues.

2. SQL Query run time - Good solutions are mentioned in the question

   • any SQL trace and performance testing will identify issues.

3. Building the report - This is where I notice the lions share of time being taken. Run a SQL trace while the report is being created. Even a relatively simple tables with lots of data can take around a minute to configure and display (HTML via apache tomcat) after the SQL trace indicates the query is done.

   • simplify the report or create a clone with fewer graphs or tables run with and without pieces to see if any create a notable difference
   • modify the query to bring back less records, less records are easier to display,

4. Delivery method PDF, Excel, HTML each can have different issues

   • try the report to different formats
   • if one is significantly greater, try different emitters.

Symon

Thanks, but unfortunately back then I tried something along those lines, to no avail - I still don't have any idea why it was so slow. At the end for this specific report I gave up using BIRT and simply rewrote everything using plain old servlets, outputting HTML directly using out.println! It was an ugly, unmaintainable CGI-like beast but at least I reached the performance level the client was expecting... – Ruddock

Answer 2

For anyone else having problems with BIRT performance, here are a few more hints.

• Profiling a BIRT report can be done using any Java profiler - write a simple Java test that runs your report and then profile that. As an example I use the unit tests from the SpudSoft BIRT Excel Emitters and run JProfiler from within Eclipse. The problem isn't with the difficulty in profiling it, it's in understanding the data produced :)

• Scripts associated with DataSources can absolutely kill performance. Even a script that looks as though it should only have an impact up-front can really stop this thing. This is the biggest performance killer I've found (so big I rewrote quite a chunk of the Excel Emitters to make it unnecessary).

• The emitter you use has an impact. If you are trying to narrow down performance problems always do separate Run and Render tasks so you can easily see where to concentrate your efforts.

• Different emitter options can impact performance, particularly with the third party emitters (the SpudSoft emitters now have a few options for making large reports faster).

• The difference between Fixed-Layout and Auto-Layout is significant, try both.

Violinist

Answer 3

Have you checked how much memory you are using in Tomcat? You may not be assigning enough memory. A quick test is to launch the BIRT Designer and assign it additional memory. Then, within the BIRT Designer software, run the report.

Vocalic