This document is intended to provide broad guidelines and parameters for hardware capacity planning purposes, based on typical usage of JasperReports Server.
Exact hardware requirements will be affected by many factors including:
- Report concurrency (number of reports run at the same time), intensity of user activity (e.g. think-time)
- Report complexity and result sizes
- Reporting RDBMS response times and performance
- JasperReports Server to repository RDBMS latency and performance
- Application server optimization and tuning
- Overall hardware performance (CPU, RAM, I/O, etc.)
Estimating Concurrent Load
Concurrent Users vs. Concurrent Report Executions
The only users placing load on a JasperReports Server instance are those who are actually performing processing actions including:
- Users processing requests, such as executing reports and exploring data through Ad Hoc views.
- Automated report execution requests made through APIs or scheduling
You can estimate the number of concurrent report executions, based on your total user population using different criteria, but it is important to distinguish between named users, active users, and concurrent report executions:
- Named users: All the users authorized to use the BI server.
- Active users: A subset of named users that are logged into the BI server at any given point in time and can demand system resources.
- Concurrent report executions: the subset of active users that are simultaneously demanding system resources at any given time.
The concurrency ratio can vary over time, and is affected by many factors. For example, the number of concurrent executions relative to active and named users tends to be higher when the user population is small. However, the most important determinant of the concurrency ratio is how processing demand is distributed over time.
Estimating Concurrent Report Executions
So we now know that 100 active users does not equate with concurrency level of 100 and that concurrency for Jaspersoft is about executing database queries and rendering query results all at the same time.
So how we can estimate this number?
As a general rule in the BI industry, the ratio of named users to active users to concurrent actions for business intelligence applications can be estimated using the 100:10:1 rule.
Factors such as geographic distribution of the user base, business hours, timezone diferences, and business practices can determine how the concurrency rate may changes over time, and these should be taken into consideration to ensure adequate capacity.
You can also use the ability to schedule automated reports, which will allow you to distribute the processing load evenly over time, so that you make the best use of your system resources to maintain optimal performance. Scheduled reports can be executed with a Snapshot option enabled and Refresh option disabled to ensure that these reports do not impose any resource requirements at the time of viewing.
Scalability and Performance Tips
JasperReports Server can be deployed as a Stand Alone application or in a Cluster deployment for high concurrency. Clustered Jasper Server Instances will use thread-safe access to their private repository database. As a result, any number of JasperReports Server instances can share the same repository and thus present the same environment to users.
In any case the repository database must be properly sized to handle the number of server instances, and it must have its own mechanism for providing scalability.
Java Application servers (like Tomcat) major strength is dynamic content generation, and they will balance loads better if they are not responsible for anything else. Configuring the load balancer on the cluster as a proxy to cache and serve static content (UI elements, css, js, etc.) will reduce the overall load on the application server.
Extensive information about clustering deployment can be found in the chapter on Designing a Cluster in the JasperServer Ultimate Guide (found in our Community Docs area).
When considering performance, bear in mind that a fast database is the biggest differentiator for Ad Hoc reporting and analysis and that network performance between all devices (including end users) will have an effect. The query time and result-set fetch time of the underling DBMS will have a direct impact in the reporting performance.
Is important to establish baselines using tools like JMeter for establishing benchmarks and measure performance before after tuning.
JVM and Application Server Tuning
JasperReports Server, like any J2EE application, depends a lot on the settings of the application server used. Even though applications servers are beyond the scope of Jaspersoft, we can offer the following guidance:
Tuning of the different settings and option in the application server (Apache Tomcat, JBoss, etc) and its JVM should be taken in to consideration. Items like database connection pooling (JNDI), threading configuration and pools, compression, garbage collection and memory reallocation, etc. have great impact on the overall performance of the applications.
- Avoid memory swapping, -Xmx should never exceed the available RAM in the system and should leave enough room for memory used by the OS and other processes that run on the same server
- Increase the Maximum PermGen (Permanent Generation) Size to at least 512m
(-XX:PermSize=256m -XX:MaxPermSize=512M )
- Set the stack to 1MB (-Xss1024k)
- Optimization (GC settings, etc), hard drive (I/O) and network connectivity are very important, follow the standard practices for your chosen Application server
- Consider clustering your application server if high concurrency is expected.
JVM Heap Memory
- Use 64-bit systems to avoid the JVM memory limits of 32-bit systems
- The minimun recommended JVM Heap Size for a production instance is 4Gb regardless the number of users.
- As a general rule assign between 1.5 to 2.5 Gb of ram per each physical core available to the JVM (Support recommends 4 Gb RAM)
- Addition of CPU cores allow an increase of concurrent report executions / sessions per machine
- It's important to consider the overhead requirements (memory and processing power) of the underlying operating system services as well as the server overall disk I/O performance.
- Follow best practices and performance tuning guidelines of your RDBMS vendor.
- Take into consideration that reporting relies heavily on multiple joins and complex grouping queries, and queries that analyze and summarize huge numbers of rows of data from multiple joined tables. This may led to different tuning techniques than the ones used for standard OLTP systems
- Network performance between all devices (including end user).
- Network latency between JasperReport Server Application and it's repository database has a great impact in the application performance.
- Hard drive and persistent storage I/O