Tuning Performance

Many variables affect the performance of JReport Server. For example, the hardware and software environment that it runs in. You may or may not have any influence in this regard, but you are able to carry out performance tuning to make JReport Server efficient, reliable, and fast.

The following lists the factors that help with the server performance:

• Use Connection Pooling either by using JNDI and the connection pool of the application server or JReport connection pooling using ConnectionPoolConfig.properties. See Configuring connection pool.
• For best performance and reliability you should change the JReport Server DBMS from Derby (the internal Java DBMS) to your standard production DBMS or other DBMS you are familiar with. Derby is included for out of the box ease of use but is not recommended for production use. See Configuring the server database on the JReport Administration page.
• Limiting the number of actively running reports can avoid momentary system overload. Setting the property performance.max.reports to a limited number in server.properties in the <install_root>\bin directory can smooth out performance and provide higher overall throughput. The best number depends entirely on your environment so needs to be configured after testing which setting provides the highest throughput in your environment.
• When using an application server, you can achieve a similar result to performance.max.reports by limiting the total number of active threads for JReport. You can assume a report consumes around 5 threads on average so setting the number of active threads to 50 is similar to setting performance.max.reports=10 but may provide better overall throughput since it is has finer granularity to control CPU utilization.
• Cache catalogs, reports, and images by configuring the Cache panel on the JReport Administration page. This is effective when the same catalogs, templates and images are used frequently but may harm performance when many different catalogs, templates and images are used and the requested resource is not in the cache. In this case, it slows performance checking the cache and wastes memory.
• Preload catalogs and reports by configuring the Configuration > Performance panel on the JReport Administration page. This will improve the performance the first time the report or catalog is used.
• Set log trace level and error level to record less information. In production servers trace level should be OFF and error level should be ERROR unless you are searching for specific issues such as monitoring the SQL statements sent to the DBMS.
• Convert reports from earlier versions into current version.
• Set task-level timeout for advanced run and scheduled tasks. This will ensure that users do not run extremely long jobs accidentally.
• Modify the JVM heap size. Again this needs some testing on your system to determine the best overall throughput. On 32-bit systems the maximum size is 2GB; however, on 64-bit systems the maximum size is extremely large. The heap usage can be monitored by tools such as the JDK jconsole application. Set a starting heap size just under your normal average usage (Use -Xms in JRServer.sh/bat) and set the maximum heap (Use -Xmx) to the maximum that you want the heap to grow. JReport can use additional heap to improve performance of queries and sorting and reducing the number of garbage collections (GC) which use CPU time. However, using too much memory for Java heap can impact performance of other applications.
• Set queue.policy=1, 2 or 3 in server.properties in the <install_root>\bin directory to turn on using priorities so on demand reports will be higher than scheduled reports. By using the different policies, you can dynamically adjust priorities so reports increase their priority the longer they wait in the queue. A third high priority queue can also be enabled for on demand reports which need to run immediately.
• Configure dhtml.properties to queue page report actions to ensure Page Report Studio features do not take too many system resources and impact other functions.
• Set engine.single_thread=true or false in server.properties. Depending on your environment and JDK, some systems run faster with a single threaded engine than with a multi-threaded engine. This needs to be tested in your environment to determine which setting provides the highest throughput.
• Set the maximum number of user handlers to the optimal size by setting the httpserver.max.handlers property in the server.properties file. This is the number of threads which are waiting to handle user requests. Setting this larger than needed wastes resources; however, setting it too small will mean that some users will not be able to access reporting until someone else exits.
• Adjust the engine's utilization of the CPU in accordance with your own requirements, by setting the Engine Priority property to a higher or lower priority on the JReport Administration page > Configuration > Advanced panel.
• Select the two options View Incomplete Pages and Format Page on Demand on the JReport Administration/Console page > Profile > Customize Profile > Page Report Studio > Properties > Advanced tab for faster viewing of the first page of large reports in Page Report Studio. The disadvantage is that to see the actual number of pages, calculate complete report totals and create the TOC, the user has to manually select the last page of the report.
• Be sure performance.exe_gc=false as the default in the server.properties file. This allows the JDK to schedule garbage collections as needed rather than at specific times.
• Minimize the usage of Word Wrap to columns which really require it. Word Wrap requires that we pre-format the data in memory to determine its size then wrap the field as necessary then continue to format it.  If fields never are large enough to wrap, especially objects like labels, it is a lot of overhead.
• True Type Fonts (TTF) provide better throughput by reducing font substitution and scaling time. Changing all the fonts to use TTF fonts improves the quality of the output as well as the performance when a mixture of operating system is used such as report design on Windows and production on Unix.
• Use binary versions of .cls and .cat, not the xml versions when you publish reports to JReport Server. This saves processing time and I/O time when converting the files to Java classes.
• Customize heartbeat interval for web browser products such as Web Report Studio, Page Report Studio, JDashboard, and Visual Analysis.

  The heartbeat mechanism is introduced in Web Report Studio, Page Report Studio, JDashboard, and Visual Analysis. It works together with user session timeout to release the unused resources of the products in time. It begins to work after any of the products is opened, by reporting to JReport Server that the product is alive per a period of time in a way similar to heartbeats. If within 4 times the heartbeat interval JReport Server has not received a heartbeat, the product will be expired and the resources be released. Heartbeat stops in the following situations:

  • The product or the related web browser is closed.
  • The computer is powered off.
  • Though the product is open, there are not any actions happening to the product such as mouse move and automatic refresh until the session times out.

  If the heartbeat interval is shorter than the user session timeout time which can be configured by the administrator on the JReport Server Administration page > Configuration > Advanced panel, the session will not expire as long as there are heartbeats. If the heartbeat interval is longer than the session timeout time, the session will be expired when the session times out.

  By default heartbeat is activated and the heartbeat interval is 15000 milliseconds. The heartbeat can be configured by adding the JVM parameter -Djrd.heartbeat in the JReport Server startup file. The parameter is used to specify the heartbeat interval in milliseconds. For example, -Djrd.heartbeat=95000.

  Heartbeat use Web Worker technology of HTML5. Web Worker is supported by Firefox, Chrome, Safari and IE10 where it is working in a separate javascript thread. But in IE9, IE8 JReport can only simulate Web Worker using iFrame, which means that the heartbeat code can be blocked by render code in IE 9 browsers.