Many variables affect the performance of JReport Enterprise 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 Enterprise Server efficient, reliable, and fast.
The process of viewing report sets is the combination of loading the report sets from the disk and generating report set files. It is obvious that skipping either of these two steps will shorten the elapsed time. JReport Enterprise Server enables the caching of report sets and catalogs into memory, so that they do not have to be loaded from disks, thereby, improving the performance.
JReport Enterprise Server can simultaneously respond to requests from the client-side. The number of the executed requests is in inverse proportion to the speed of the response. The more requests that are executed, the slower is the speed. To speed up running, you can set user handlers to be a comparatively small number.
The performance of JReport Enterprise Server is influenced by the usage of the CPU that JReport engine can occupy. A larger share of CPU usage will speed up the performance. JReport Enterprise Server provides you with an option called Engine Priority, which allows you to adjust the engine's utilization of the CPU in accordance with your own requirements. To tune JReport Enterprise Server for best performance, you can modify this option to enable the engine to share a larger part of CPU usage when it is running.
When JReport Enterprise Server receives a report running request (background run or schedule run), it creates a task for running the report and bundles the task to a thread. The task will create a new engine instance and start to run the report.
If there is no queue control, the above process goes on until the maximum number of concurrent reports permitted by the license is reached, and requests that exceed the permitted number will be refused.
Queue control is used to reduce the maximum number of concurrent reports to a smaller number than that permitted by the license so as to meet your system performance requirement.
If queue control is adopted, a task will create a new engine instance for running a report and occupy a place for the report in the queue. Once the queue is full, requests that exceed the queue size will have to wait for a free place in the queue. Only after a report finishes running, the associated place in the queue will be released and the server can run another report.
You can increase or decrease the queue size by setting the property performance.max.reports in server.properties file in the <install_root>\bin directory. Setting this property to a suitable value will lead to marked improvement in performance.
When using queue control you can set the priority of tasks waiting in the queue to run. To use task priority, set performance.max.reports to the number of reports you want to run concurrently then set queue.policy to 1, 2 or 3 depending on your requirements. You can also set queue.accelerated.size to a number greater than 0 and less than performance.max.reports to set the number of reports running in the accelerated queue. The queue.accelerated property sets the priority levels required to run in the accelerated queue. The purpose of these properties is to allow high priority on-demand tasks to jump in front of slower running scheduled tasks which may be running in the normal queue.
For example you might set the following properties in server.properties file located in <install_root>\bin:
performance.max.reports=20
queue.accelerated=10,9
queue.accelerated.size=5
queue.policy=1
When you schedule reports to run they will by default run at priority 5 and when you run reports on-demand you can specify their priority so if you have many longer running reports running you can put them at priority of 8 or less so up to 15 of them will run concurrently. This allows 5 slots for higher priority on-demand reports to run immediately when requested so any reports with a priority of 9 or 10 will run in the accelerated queue and will not be held in the waiting queue until the long running reports are completed.