Reports/Dashboards often time out or take too much time even when they do load. I have tried various performance settings recommended in admin guide and also here http://community.jaspersoft.com/questions/821769/aws-jaspersoft-performance, But no noticable performace improvements.
Things that tried
- Optimize queries for both Domain based and JDBC based
- Change row limit and query time out
- Settings to cache snapshots
- Change tomcat setting to remove no cache headers so that api's are cachable, its sad too see these basic stuff have to be done manually for paid software and doesn't come in built.
We are using redshift as database and its very fast ( tested by running queries generated by jasper manually). Data for our most of the reports does not change for atleast a day, i was hoping these get cached and subsequent report loads will be faster, but thats not the case. One of the queries for getting unique users is terffically slow, where as sql qury to do the same is responds very fast.
Can you please recommend any other settings etc to make them faster?
We have the same issue here in the On Demand version. The queries are really fast (in tens of milliseconds), but still a dashboard with just couple of pie charts takes a lot of time (>15 seconds) to load. We found a lot of scripts being loaded on the client (around 400 http requests for such a simple dashboard iprimarily consisting of scripts (fewer images and css)). Most of these scripts cant be cached as they are loaded dynamically using url parameters even if you set cache headers. Really don't understand the reason why it is done so. Are we doing something wrong. Can someone help with a solution. If it is some wetting changes, why can't it be defaulted.
We are sorry to learn of the peformance issues you are encountering.
There are a couple items that we are exploring that could be the root to the performance issue you are encountering:
1) Instance size. If you are both using m1.medium, please be aware that it is only made available as a low-cost evaluation and development environment. Most customers seem to be successful with m1.medium for these purposes. Having said that, a bigger instance may address your issue. For production, four cores (such as in a Standard XL m1.xlarge) is generally suggested. If you would consider testing on a bigger instance, we would appreciate your further feedback.
2) client / chatter dialog in v5.5 and before. This is being addressed to reduce chatter in v5.6 which is scheduled to be GA within weeks.
TIBCO, Jaspersoft Product Group
Director, Cloud Services