nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Speeding Up Report Running

dan3874

I have a complex report that takes 5 minutes to run. I am using Eclipse 3.6.2

Here are some of the design specs I'm using:
# 3 data sources
# 13 data sets
# 2 data cubes
# 56 tables

I have nested Grids and Tables for ease of organizing the material. For example in the header section I have:
Grid -> Grid -> Grid -> Table. That's all the further deep it goes, but I have 6 tables in that cell where the table is, each pointing to the same data source but filtered differently.

If the number of tables is the resource hog, I would love any suggestions on how to filter information as it comes from the SQL so that I can pick specific answers from the SQL results into different fields in the table.

Also, is there a way to get some report back regarding what's going on inside the report as it runs? I'm thinking I'd like to see how long different parts are taking. How long is it taking to connect to the data sources, how long to get back the SQL results, how long to build the different tables, etc. The BIRT Server is run in one state and the data sources are in another state, but it's all an internal network that does not have much latency.

any help would be appreciated!

Find more posts tagged with

Comments

Yaytay

A few pointers that might help.

Tools for monitoring your database access, your network access and file accesses can help to pinpoint the source of performance issues (in general, and in particular with BIRT).
Look for whether BIRT is pushing data to the rptdocument whilst queries are still sending data down the wire (this is the desired behaviour, but is not the default with either MySQL or MS SQL).
See how long your queries take to run without using BIRT.

You can also use a tool like jProfiler to get a better view of what is happening, the source for BIRT is easily downloadable, so jProfiler can provide complete visibility of what is happening.

mwilliams

So, you don't have tables nested within tables or anything like that?

When you say, "I have 6 tables in that cell where the table is, each pointing to the same data source but filtered differently", are you actually using a single dataSet and filtering each table to only get what it needs? If so, it would be faster to create a separate dataSet for each table or use a dataSet parameter in the dataSet and set the dataSet parameter value via the binding tab of the table. Unless there's just a small amount of data to filter, this would slow things down a lot. As a general rule, the earlier you can limit the data the better. If you have large amounts of data that get filtered over and over by BIRT, it'll slow down the report. If you have to filter, the best place to filter is on the dataSet itself. Though, letting the SQL do the data filtering work is the fastest, by far.

dan3874

Wow, what a difference in speed! This report now run consistently in 30 seconds , or so! I now have over 50 data sources and am amazed at the difference.

I was thinking exactly opposite! I figured one reasonable call to the database and then with that data in the memory of the BIRT Server, I could let BIRT simply pull out specific stuff for each table.

Thank you for setting me straight and turning my thinking around!