Optimal Report Server Performance

InetSoft's reporting software allows users to make the adjustments needed for optimal report server performance. View the example below to learn more about the Style Intelligence solution.

Server performance options are available on the 'Configuration' > 'Performance' page under the Server tab. These options primarily control how data is cached.

The options on the 'Performance' page should be set according to the server's memory size and the performance characteristics of the application.

The 'Maximum Concurrency' property determines the maximum number of sessions allowed at any given time. Concurrency is the number of simultaneous user sessions that the report engine will support. A user session is initiated when the user logs in, and terminates when the user logs out or when all the reports associated with the user's session time out.

#1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index Read More

InetSoft Report Server example
InetSoft Report Server sample

The 'Composer Live Data Timeout' setting determines the maximum amount of time to allow for 'Live Data' requests in Visual Composer. The timeout setting may not be honored equally by all databases.

The 'Composer Live Data Maximum Row Count' setting determines the maximum number of rows to retrieve for 'Live Data' requests in Visual Composer. The maximum row count setting may not be honored equally by all databases.

The 'Ad Hoc Timeout' setting determines the maximum amount of time to allow for Ad Hoc report requests. The timeout setting may not be honored equally by all databases. See Ad Hoc Reporting for more information.

The 'Ad Hoc Maximum Row Count' setting determines the maximum number of rows to retrieve for Ad Hoc report requests (preview or final report). The maximum row count setting may not be honored equally by all databases. See Ad Hoc Reporting for more information.

The 'Cache Interval' specifies the elapsed time (ms) between cache swaps. At the specified interval, the server checks, swaps, and prunes cached pages according to their age and access time.

A “workset” is the number of report pages that are frequently accessed within a given period of time. For example, if most users only read the first three pages of a report, then the workset is 3. The 'Workset Size' setting is used by the caching algorithm to optimize the swapping of files to disk.

The 'Maximum Reports Per Session' option controls how many reports a session can open and keep active. If a session contains more active reports than the threshold, the older reports are destroyed to conserve memory (FIFO).

The 'Cache Security Provider Data' option, when set to 'true', enables the caching of user, role, and permission information. This is recommended.

InetSoft Report Server output
Read the top 10 reasons for selecting InetSoft as your BI partner.

What Slows Down Report Server Performance?

Many factors can slow down report server performance, and identifying these bottlenecks is key to optimizing execution time. Below are the main culprits that can degrade report server performance, categorized by data retrieval, report design, caching inefficiencies, server configuration, and external factors.

1. Inefficient Data Queries

Since most reports pull data from databases, inefficient queries can cause major slowdowns.

Heavy or Poorly Optimized SQL Queries

  • Using SELECT * Instead of Selecting Required Columns
    → Retrieves unnecessary data, increasing processing time.
  • Lack of Indexing on Frequently Queried Columns
    → Causes slow table scans instead of fast indexed lookups.
  • Complex Joins on Large Tables
    → Increases processing time, especially if foreign keys are missing indexes.
  • Unoptimized Subqueries
    → Nested subqueries can be slow; using joins or Common Table Expressions (CTEs) is often faster.
  • Unfiltered Queries (No WHERE Conditions)
    → Retrieving all rows when only a subset is needed adds unnecessary load.

High-Latency Data Sources

  • Pulling data from multiple remote databases or APIs can introduce latency.
  • Slow connections between the report server and the database impact retrieval time.

Lack of Data Pre-Aggregation

  • Performing aggregations within the report instead of in the database increases report execution time.
  • Not using materialized views, indexed views, or summary tables.

2. Poor Report Design

The way reports are structured significantly affects their performance.

Excessive Data Volume in Reports

  • Pulling millions of records when only summary-level data is needed.
  • Not implementing pagination for large datasets.

Heavy Use of Calculated Fields and Expressions

  • Complex expressions (especially nested ones) slow down rendering.
  • Aggregations and calculations should be pre-processed in the database when possible.

Overuse of Conditional Formatting

  • Dynamic formatting (changing colors, visibility, etc.) adds rendering overhead.
  • Using too many expressions for visibility settings increases processing time.

Complicated Charting and Graphing

  • Large datasets plotted in detailed charts (instead of summarized data) can cause lag.
  • Charts with excessive data points instead of aggregated information.

3. Inefficient Caching and Report Execution Mode

Caching helps improve performance, but if not used properly, it can degrade performance instead.

Not Using Report Caching or Snapshots

  • If each report request runs a fresh database query, response times suffer.
  • Cached versions of frequently accessed reports should be used.

Frequent Data Refresh for Static Reports

  • Reports that don't need real-time data should use snapshots or pre-processed datasets.
  • Constantly reloading static data wastes server resources.

Failure to Leverage Shared Datasets

  • If multiple reports use the same dataset, but each one queries separately, performance suffers.
  • Shared datasets or views should be used instead.

4. Report Server Configuration Issues

The server's hardware and software settings can directly impact report execution speed.

Insufficient Memory (RAM)

  • Large reports consume a lot of memory; if insufficient RAM is available, the system swaps to disk, slowing down performance.

CPU Overload

  • Running multiple reports simultaneously or executing CPU-intensive queries can bottleneck performance.
  • Poor query optimization and excessive calculations can cause unnecessary CPU load.

Inefficient Thread and Parallel Processing Configuration

  • Some report servers allow parallel execution of datasets; disabling this feature can slow down reports.

Slow Disk Performance

  • If the server frequently reads/writes temporary data to a slow disk, it slows down report execution.
  • SSDs are preferable for high-performance report servers.

5. Network and External Factors

Reports often depend on external data sources and network connectivity.

Slow Database Connection

  • If the report server and database are on separate networks or datacenters, slow connections can cause bottlenecks.
  • High network latency between report server and data source degrades performance.

Concurrent Report Requests Overloading the Server

Security and Authentication Overhead

  • If every report request requires complex authentication checks, it can introduce a delay.
  • Single sign-on (SSO) or token-based authentication can improve response time.

6. Data Integration and Transformation Issues

If the report server is combining data from multiple sources, performance can suffer.

Use of Multiple Data Sources Without Optimization

  • If data needs to be fetched from multiple systems (e.g., SQL, APIs, flat files), this can cause slowdowns.
  • Using a data mashup tool like InetSoft can help by pre-processing and merging data before report execution.

Lack of ETL (Extract, Transform, Load) Optimization

  • Transformations happening on-the-fly in the report instead of during the ETL process add overhead.
  • Pre-transforming data using an ETL process improves report efficiency.

How to Identify and Fix These Issues?

  • Use Database Query Profiling (EXPLAIN ANALYZE in PostgreSQL, Execution Plan in SQL Server) to identify slow queries.
  • Enable Logging and Performance Monitoring in your report server to track slow-running reports.
  • Use Caching and Snapshots to reduce repetitive queries.
  • Optimize Server Resources (RAM, CPU, Disk) and scale out if necessary.
Previous: Localizing Report Elements