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; } } }

Possible ways to increase report generation performance

getza1

We have a report that is taking a really long time to generate when we start getting above 100,000 records. When profiling the report generation I noticed that it caches the result set to disk and then does sequential reads on the file. I tried setting the DataEngine.MEMORY_BUFFER_SIZE to 900MB so it would hold the whole result set in memory and not cache to disk. Yet I still see the file being created and calls to ResultObjectUtil.readData(). For one particular report it made around 900 calls to that method.

Is there a way to speed up the generation of reports? We have creating PDF reports. I have searched Google and the forum and haven't really found any information regarding this. Just posts on how to get BIRT to use less memory. I have attached a graph which shows how the increase in records is impacting the increase in report generation time.

Let me know if there is anything else that I can provide to get better feedback such as the report design, etc.

Thanks,

Aaron

Find more posts tagged with

Comments

getza1

Forgot to attach the graph.

getza1

Forgot to attach the graph.

johnw

What is in the report? Can you post the RPTDocument (with a small recordset) so we can take a look. A lot of different factors come into play for report performance, such as number of elements, properties set on those elements, etc.

getza1

I can post the report design but I most likely will not be able to post a small data set. If this is an issue I might be able to mock up some data.

CBR

The report seems to be quite complex to me because it has a lot of nested groups on the outer list. Would it be possible to already group the data accordingly using SQL, so that you can remove the groups from the list and use detail rows instead? Another thing that would increase performance is the cube. There is a checkbox to tell the cube that the data is already aggregated before it hits the cube: I would suggest to always use SQL to group the data instead of bringing the cube into play (it doesn't matter much if the dataset only contains about one hundred rows but if its a few hundred it definitly makes a difference).

In BIRT 3.7 you can deactivate the dataset cache (i think that this option was already existing in BIRT 2.6.x but didn't worked).

What's the Xmx setting on your dev machine? (you have to keep in mind that the postgres jdbc driver already loads the whole resultset into memory before even returning the first result row, because the set up looks like you are not streaming the rows)

getza1

Thanks for the tips. We are starting to try and push the grouping into the database layer. The Xmx on my machine is set at 2GB. We ended up generating a report for each grade instead of having all the grades in one report. This increased the performance because it is now working on a smaller dataset. Although when we aggregate it is taking about twice as long to generate the report. Using your suggestions of doing the grouping at the database level should help this.