Cognos BI application tier
The Cognos® BI application tier can contain one or more servers (for example, report servers). Such a server runs requests, for example, reports, analysis, and queries, that are forwarded by a gateway.
The SUT has two Cognos BI report servers as application tier, each in its own virtual machine. Both virtual machines also run a dispatcher service that starts and controls the report service in its instance.
The Cognos BI Gateway was configured to send any requests to the first available dispatcher service in its list of known dispatchers. When a dispatcher service starts, it registers itself with the Content Manager. As a result, each dispatcher is aware of the other dispatchers and can route requests to other present dispatchers. This enables the capability of workload balancing between the dispatchers and hence also between both report servers. The Cognos BI Gateway itself does no request routing between the Cognos BI report servers.
For more information on the Cognos BI Application tier, refer to the IBM® Knowledge Center for Cognos Business Intelligence 10.2.1:
- Cognos Business Intelligence 10.2.1 > Install > Business Intelligence Architecture and Deployment Guide 10.2.1 > The Multitiered Architecture > Tier 2. Applications: IBM Cognos BI Servers
Also refer to the following technical article on IBM developerWorks®:
IBM Business Analytics Proven Practices: IBM Cognos BI Dispatcher Routing Explained
Report Server tuning
WAS Java™ virtual machine heap size
The WAS report server initial and maximum Java virtual machine (JVM) heap size was set to 1024 MiB and 2048 MiB respectively. Increasing the JVM heap may often improve performance.
WAS administration console path:
Servers → Application Servers → server1 → Java and process management → Process Definition → Java Virtual Machine
WepSphere WebContainer thread pool
The WAS Thread Pool WebContainer maximum was increased from default 50 to 500. Increasing the maximum will improve scalability for the Cognos BI report server.
WAS administration console path:
Servers → Application Servers → Server1 → Thread Pools → WebContainer
Report Server session cache
The default processing behavior for the Cognos BI Report Server can be changed by modifying entries in the rsvpproperties file. Depending on your specific IBM Cognos BI application and requirements, changing settings in the rsvpproperties.xml file may improve the performance.
A rsvpproperties.xml.sample file is located in the <cognos10_location>/configuration directory.
If required, just copy the sample file to the file rsvpproperties.xml.
One parameter which is important for the performance, is the maximum size of the session cache maintained by the report server. It was increased from 20 to 100.
... <property>SessionCacheSize</property <value type=”long”>100</value> ...
Number of processes for the report service
The report service, batch report service, and report data service have several settings that you can configure to optimize the use of system resources.
There are a number of processes associated with the report service and the batch report service. When these services receive requests from the dispatcher, they start processes to handle the requests (also known as BiBus processes). You can specify the maximum number of processes that these services can start any time.
The report server execution mode was explicitly set to 64-bit for the SUT.
For more information on the report server execution mode see:
- Differences between running a 32 and 64 bit Report Server with IBM Cognos 10.1 RP1 (10.1.1) and above
- IBM Knowledge Center for Cognos Business Intelligence 10.2.1:
Cognos Business Intelligence 10.2.1 > Install > Installation and Configuration 10.2.1 > Installing and Configuring Server Components on Different Computers > Installing and Configuring Application Tier Components > Enable the 64-bit version of report server
The number of processes should be configured based on the amount of available capacity provided by the Cognos report server. In general, report processing is a CPU-bound process. As a result, the number of CPUs for the server are the main variables to keep in mind when adjusting this setting from the default value of 2.
Figure 1 shows the transaction throughput and response times when scaling the number of report service processes from two to eight processes.
The two report servers in the SUT are defined with four virtual CPUs each. The default value of two system-wide report service processes for a single report server gives lower results in this case.
When setting the number of processes equal or higher than the number of available CPUs, the report server is much better utilized and delivers a higher transaction throughput and lower response times.
Setting the number of processes for the report service for peak and non-peak periods:
Cognos Connection path:
Configuration → Dispatchers and Service → Set properties → Report Service →Tuning → Settings
Query Service - Java virtual heap size
The initial and maximum heap size for the Query Service was increased to 4096 MiB.
Cognos Connection path:
Configuration → Dispatchers and Service → Set properties → Query Service → Settings
Remarks on the Report Server memory footprint
All tuning mentioned above indicates that the memory footprint for the report server can get very big. The following memory-consuming components need to be considered together:
- WAS JVM heap size (2 GiB)
- Query service JVM heap size (4 GiB)
- number of processes for the report service (can grow to more than 1 GiB memory per process)
Figure 2 shows the memory consumption for four report service processes over three hours at a continuous workload level.
All four processes grow to 1.2 GiB memory in parallel. From time to time, a single process becomes idle and is stopped by the report service. Due to the ongoing workload, a new process is created that again grows over time.
Conclusion: There is a recommendation of setting up two report service processes (31-bit) per available report server CPU. We used 64-bit report service processes for the SUT and there was no performance difference between one process per CPU versus two processes per CPU. But with two processes per CPU, the memory requirements for the processes may also double.
The Cognos BI report servers were enlarged to 16 GiB memory each in order to satisfy the memory requirements of already 11 GiB for Cognos services and WAS Java heaps for one instance.