Web Intelligence Server Performance Test

How well the Web Intelligence Server processes requests depends upon many factors, including:

  • The amount of CPU resources allocated to the server;
  • The amount of memory allocated to the server:
  • The thread pool size

If the server experiences CPU/memory contentions or runs short of free threads, it is bound to affect the speed with which it processes requests, thus resulting in a server slowdown. This is why, administrators are advised to periodically run the Web Intelligence Server Performance test. At pre-configured intervals, this test measures the CPU and memory usage of the Web Intelligence server and alerts administrators to threshold violations (if any). In addition, the test also checks for free threads in the thread pool, and if only a few free threads are available, warns administrators of a potential processing bottleneck.

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 Web Intelligence 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

CPU usage

Indicates the percentage of CPU resources used since the server started.


A value close to 100% is indicative of a CPU contention on the server.

Memory high threshold violation rate

Indicates the rate at which the Memory Upper Threshold  was violated by the server in the last measurement period.


If Memory Analysis property is enabled on the server, then the following properties can be configured and tracked on the server:

  • Memory Maximum Threshold
  • Memory Upper Threshold
  • Memory Lower Threshold

When the server's process memory is above the Memory Upper Threshold, the only operation that is allowed is saving documents. When the process memory is above the Memory Maximum Threshold, all operations stop and fail.

It is evident then that such threshold violations are not good news! Ideally therefore, the value of the Memory high threshold violation rate and the Memory max threshold violation rate measures should be 0. A non-zero value is a sign of frequent memory threshold violations, which could either indicate a serious memory crunch on the server or an improper threshold setting. If further investigations reveal a memory contention on the server, make sure that you allocate more memory to the server to avoid the same.

Memory max threshold violation rate

Indicates the rate at which the Memory Maximum Threshold  was violated by the server in the last measurement period.


Virtual memory size

Indicates the amount of memory assigned to the server.



Active threads

Indicates the number of threads (from the asynchronous thread pool) that are currently serving user requests to the server.


If this measure reaches the configured maximum thread pool size for the server, new requests to the server would have to wait until a server thread becomes free. If this happens often, it may significantly slowdown request processing by the server. In such a situation, you may want to consider resizing the thread pool.

Current number of auditing events queued

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


If this number increases without bound, it could 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 the servers first and wait for auditing events to be fully retrieved and this queue to become empty. Otherwise, they may be retrieved only when the server has been restarted and the CMS polls for them.