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

BIRT Engine API: Caching

boulos

Hello,

I am trying to generate reports using the Report Engine API. I faced two major problems on performance:
1- The size of the BIRT rpt document is huge. For a report with 7000 rows and 15 columns, the size of the document is 3GB !!!. The size of the pdf was 3MB and the size of the HTML was 46MB.
The special in the report is that it contains nested groupings and aggregations. Is this normal?
2- The report generation is very slow, it takes about 5 minutes to generate the report above. After debugging a bit, I found out that the caching was done on the disk. After setting a property to do the caching in memory, the time dropped to 95 seconds. Is this expected?

In the end, I want to ask about the recommandations for improving the performance of such reports. Are these defined somewhere?

Thanks,
Boulos

Find more posts tagged with

Comments

boulos

mwilliams

Are you using SQL databases? Or another type? If using SQL databases, do you use dataSet parameter binding to limit your embedded tables? Or do you simply use filters? Using filters will decrease your performance. Also, what is your BIRT version?

boulos

<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="111176" data-time="1351892093" data-date="02 November 2012 - 02:34 PM">
Are you using SQL databases? Or another type? If using SQL databases, do you use dataSet parameter binding to limit your embedded tables? Or do you simply use filters? Using filters will decrease your performance. Also, what is your BIRT version? </blockquote>
 
yes i am using SQL. what do you mean by "dataSet parameter binding"? 
i am not using filters at all. i have a simple select statement from a table with a where clause. my sql looks like this: 
select a,b,c from table where d=? and e<= ? and e>=? and f like ? 
then created 4 report parameters so i can set the values for my where clause dynamically. 
i am using 3.7.2

mwilliams

I see. When you said nested groupings, I took that as having embedded tables. The simplicity of the design, the amount of data, and the hardware you're running on are obviously big factors in speed. From the sounds of it, you have lots of data, so that will cause the report to take longer than one with just a few rows, especially with grouping. I'd have to look at the design to see if there is anything that might be able to be designed differently, to speed it up. You can attach the design, if you'd like me to look.

boulos

<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="111238" data-time="1352160614" data-date="05 November 2012 - 05:10 PM">
I see. When you said nested groupings, I took that as having embedded tables. The simplicity of the design, the amount of data, and the hardware you're running on are obviously big factors in speed. From the sounds of it, you have lots of data, so that will cause the report to take longer than one with just a few rows, especially with grouping. I'd have to look at the design to see if there is anything that might be able to be designed differently, to speed it up. You can attach the design, if you'd like me to look. </blockquote>
 
hello,

mwilliams

In your case, it might help to use embedded tables and dataset parameters. You could create a dataSet for each grouping and have a where statement to link it to the dataSet that will be outside it, in the table. This would make for more calls to your db, but it would only call the data needed at the time, rather than processing the large resultset to create the groups. It's worth a shot. I'd create a new report to try, rather than reworking your currently working report, so you don't lose it.