Dashboards Cache Server Performance Test

Ideally, the cache server should be able to serve maximum report requests. If it cannot, then client queries will be routed to the Dashboard Processing Server, which will fulfill the requests by running the queries on the database. This will considerably increase databases accesses and related processing overheads. To minimize these overheads, administrators should continuously monitor report requests, measure how quickly and efficiently the cache server services these requests, and detect deficiencies in cache usage/performance (if any). This is exactly what the Dashboards Cache Server Performance test does. This test reports how well the Database Cache Server is utilized and how quickly it processes requests. In the process, the test points to poor cache usage and processing bottlenecks, and also reveals if it is because the server is badly sized.

Target of the test : A SAP BOBI Node

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for the Database Cache Server in the node monitored.

Configurable parameters for the test
Parameter Description

Test period

How often should the test be executed.


Host name of the server for which the test is to be configured.


Enter the port to which the specified host listens. This should be the port at which the web application server hosting SAP BOBI listens.

JMX Remote Port

Specify the RMI port number of the BOBI monitoring application.To know the RMI port number of the monitoring application, refer to Enabling the Monitoring Application of the SAP BOBI Platform.


Specify the lookup name for connecting to the JMX connector of the BOBI monitoring application. To know the JNDI name, refer to Enabling the Monitoring Application of the SAP BOBI Platform.

JMX User and JMX Password

Enter the credentials of an enterprise authenticated BOBI user belonging to the default monitoring users group.

Confirm Password

Confirm the password by retyping it here.

Node Name

Specify the name of the BOBI node being monitored.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Cache hit rate

Indicates the percentage of requests, over the last 500 requests, that have been served with cached data.


A value over 80% is ideal. A value less than 50% is a cause for concern, as it indicates that a vast majority of requests for reports is not served by the cache server. This increases database accesses and related overheads, and hence, should be avoided.

Requests served rate

Indicates the rate at which the server serviced requests.


A low value or a steady drop in the value of this measure is indicative of a processing bottleneck.

Average processing time

Indicates the average time taken by the server to process a request.


A low value is desired for this measure. A high value indicates that the server is taking too much time to process requests. This could be owing to a processing bottleneck and warrants closer scrutiny.

Queued requests

Indicates the number of requests that are either waiting for processing or are being processed.


A steady rise in the value of this measure is a sign of a request queue that is growing. This means that the server is unable to process page requests as quickly as it receives them.

Current cache size

Indicates the current size of the cache.


A large cache size may be necessary if the server needs to handle large numbers of queries, or highly complex queries. You may want to increase the cache size if the Cache hit rate, Requests served rate, and Average processing time measures exhibit disturbing trends.

Open connections

Indicates the number of connections open between the server and its clients.



Data transfer rate

Indicates the rate at which data is transferred from the server to its clients.



Current number of auditing events queued

Indicates the number of auditing events that this server has recorded, but which have not yet been retrieved by the CMS Auditor.


If this number increases without bound, it could mean indicate that auditing has not been configured properly or that the system is heavily loaded and generating auditing events faster than the auditor can retrieve them.  When stopping servers, it is advisable to disable them first and wait for auditing events to be fully retrieved and this queue becomes empty. Otherwise, they may be retrieved only when this server has been restarted and the CMS polls for them.