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

Report generation Performance

Julien401

Hello, 
 
I have been running Birt in a GWT app for a few months and it works very well. 
My only concern is about performance in rendering. I have to regenerate the reports (html format with svg charts) at every single click. My reports are pretty simple, average is 2 dynamic texts and 1 chart. 
I have been working a lot on caching stuff I could and I get almost everything done in less than 100ms. 
Then it goes to <pre class='_prettyXprint _lang-auto _linenums:0'>IRunAndRenderTask.run()</pre>: I get a variable time between 3 and 30 seconds. 
 
I have checked my datasource .execute() and .next(), so far it is very fast (and there are not so many rows - less than 100). 
 
I feel like there is something wrong because rendering is pretty fast inside eclipse in preview mode (below the second). 
 
Logs are OFF. 
 
Engine is loaded at startup, designs are cached, I did not see any need to make a task pool. Maybe this is the point, but <pre class='_prettyXprint _lang-auto _linenums:0'>IRunAndRenderTask task = birtReportEngine.createRunAndRenderTask(design)</pre> has a very low cost. 
 
Any suggestion?

Find more posts tagged with

Comments

JasonW

This does seem slow. I doubt caching will have any effect on this small amount of data though. The data engine appcontext cache related settings are:

DataEngine.DATA_SET_CACHE_ROW_LIMIT
This setting allows user to cache a data set in disk. If set to negative value, all rows in data set will be cached. If set to zero, the function is disabled. If set to positive number, specific number of rows will be cached. Should only be used in a design situation.
Change setting to clear.

DataEngine.MEMORY_BUFFER_SIZE
Memory per Query that is used before caching to disk. Defaults to 10 MB. Used inside and outside of designer.

DataEngine.MEMORY_DATA_SET_CACHE
This setting allows user to cache a data set in memory. If set to a number equal or less than zero, the function is disabled. If set to a positive number, exactly that number of rows will be saved to memory. Should only be used in a design situation.
Change setting to clear.

use config.getAppContext().put... to set them

Any chance as a test you could try the new BIRT 3.7 runtime?

Jason

Julien401

<blockquote class='ipsBlockquote' data-author="'JasonW'" data-cid="79001" data-time="1308854850" data-date="23 June 2011 - 11:47 AM">
This does seem slow. I doubt caching will have any effect on this small amount of data though. The data engine appcontext cache related settings are: 
 
DataEngine.DATA_SET_CACHE_ROW_LIMIT 
This setting allows user to cache a data set in disk. If set to negative value, all rows in data set will be cached. If set to zero, the function is disabled. If set to positive number, specific number of rows will be cached. Should only be used in a design situation. 
Change setting to clear. 
 
DataEngine.MEMORY_BUFFER_SIZE 
Memory per Query that is used before caching to disk. Defaults to 10 MB. Used inside and outside of designer. 
 
DataEngine.MEMORY_DATA_SET_CACHE 
This setting allows user to cache a data set in memory. If set to a number equal or less than zero, the function is disabled. If set to a positive number, exactly that number of rows will be saved to memory. Should only be used in a design situation. 
Change setting to clear. 
 
use config.getAppContext().put... to set them 
 
Any chance as a test you could try the new BIRT 3.7 runtime? 
 
 
Jason </blockquote>
Hello Jason, 
Thanks for your answer. Not sure what means "Should only be used in a design situation", what would it be in a production situation? Defaults to cache enabled? 
 
I tried these parameters with high values on a dedicated machine with tomcat Xmx at 2048M, which seems to me plenty of RAM for a single user. 
I did not encounter the kind of "freeze" (=wait 30sec) today, but maybe I should test further. Now, chart appear after 2 to 6 sec. 
 
I am gonna give a try to version 3.7 first, but this will take sometimes, because I will have to isolate it on a dedicated environment.

JasonW

Design situation means you should only set this if you building some kind of design tool where it is ok to not refresh the data or it is ok to not retrieve all the data. For example fetch limit will limit the total rows returned.

Jason

Julien401

<blockquote class='ipsBlockquote' data-author="'JasonW'" data-cid="79038" data-time="1308926775" data-date="24 June 2011 - 07:46 AM">
Design situation means you should only set this if you building some kind of design tool where it is ok to not refresh the data or it is ok to not retrieve all the data. For example fetch limit will limit the total rows returned. 
 
Jason </blockquote>
Thanks for your answer. I only kept the memory buffer size at 100M <pre class='_prettyXprint _lang-auto _linenums:0'>DataEngine.MEMORY_BUFFER_SIZE</pre>
I expect each query to be run in a short timeframe, so this would use around 1G in total in worst situations (wild guess based on 10 charts generated at the same time, which would be around 100 concurrent users). 
 
The 3.7 version is a big improvement in terms of perf. I had some issues during migration, because we loose the jar isolation capability from eclipse. But once this worked out, it runs fine. 
 
I also tried to make some small modifications on the charts. I realized some very simple things can make a big change: I saved 200ms at generation time only by removing the value of the series on top of each bar in histograms. I guess the position calculation was somewhat complex. 
 
Now I can see a generation time always below the sec, with an average around 500ms. I have detailed numbers, but this would not give much more info ... My main point in the current situation is that task.run() is very expensive in terms of CPU: I can get a quadcore CPUs busy at 100% during the 500ms of the generation, I guess this task is all about calculation. I would have to investigate a little more to see if this has to do with GC. 
 
I think this result is very acceptable for production. Thanks for your help, and if you could point me to some resources about designing reports for performance I would be very happy.

JasonW

Take a look at this ppt:
http://www.birt-exchange.org/org/devshare/designing-birt-reports/371-designing-high-performance-birt-reports/

Jason

Julien401

<blockquote class='ipsBlockquote' data-author="'JasonW'" data-cid="79128" data-time="1309196381" data-date="27 June 2011 - 10:39 AM">
Take a look at this ppt: 
<a class='bbc_url' href='http://www.birt-exchange.org/org/devshare/designing-birt-reports/371-designing-high-performance-birt-reports/'>http://www.birt-exchange.org/org/devshare/designing-birt-reports/371-designing-high-performance-birt-reports/</a> 
 
Jason </blockquote>
Thanks for the pointer. Very clear and simple. It goes deeper into where I started to look: You first need to make sure your database performs well, then try to make charts with no complicated calculations (3D, labels on top of bars ...). 
I also tested somewhat further, and I am happy the results I get are pretty much constant while having multiple clients.

JasonW

I am glad to hear.

Jason