Ensuring optimal performance of your Web Intelligence Server is crucial for maintaining efficient operations. Several factors can influence how effectively the Web Intelligence Server processes requests, including the CPU resources, memory allocation, and thread pool size. When a server faces constraints in CPU or memory, or if it runs out of available threads, the processing speed of requests inevitably decreases, leading to server slowdowns. To proactively manage this, administrators are advised to periodically conduct the Web Intelligence Server Performance test. This test is designed to measure the CPU and memory usage of the Web Intelligence server at pre-defined intervals, alerting administrators to any breaches of set thresholds. Furthermore, it assesses the number of free threads within the thread pool, providing warnings of potential processing bottlenecks if the available free threads are limited.
This test is specifically targeted at a SAP BOBI Node and can be deployed by an internal or remote agent. The output consists of a result set for the Web Intelligence Server within the monitored node.
Configuration parameters for the test include:
| Parameter | Description |
|---|---|
| Test period | Defines the frequency of test execution. |
| Host | Specifies the host name of the server to be tested. |
| Port | The port number the host listens to, typically the port for the web application server hosting SAP BOBI. |
| JMX Remote Port | The RMI port number for the BOBI monitoring application. Refer to the SAP BOBI platform documentation for details on enabling the Monitoring Application and identifying this port. |
| JNDI Name | The lookup name for connecting to the JMX connector of the BOBI monitoring application. Refer to the SAP BOBI platform documentation for details on enabling the Monitoring Application and identifying the JNDI name. |
| JMX User and JMX Password | Credentials for a BOBI user with enterprise authentication, belonging to the default monitoring users group. |
| Confirm Password | Password confirmation. |
| Node Name | The name of the BOBI node being monitored. |
Key measurements provided by the test are outlined below:
| Measurement | Description | Measurement Unit | Interpretation |
|---|---|---|---|
| CPU usage | Percentage of CPU resources utilized by the server since its start. | Percent | High values, nearing 100%, indicate potential CPU contention. |
| Memory high threshold violation rate | Frequency at which the server exceeded the Memory Upper Threshold in the last measurement period. | Violations/Sec | When Memory Analysis is enabled, thresholds like Memory Maximum, Upper, and Lower are configurable. Exceeding the Memory Upper Threshold limits operations to saving documents only, while exceeding the Maximum Threshold halts all operations. Ideally, this rate and the Memory max threshold violation rate should be 0, indicating stable memory conditions. Non-zero values suggest frequent memory threshold breaches, possibly due to memory shortages or incorrect threshold settings. Investigate server memory allocation if contention is detected. |
| Memory max threshold violation rate | Frequency at which the server exceeded the Memory Maximum Threshold in the last measurement period. | Violations/Sec | See interpretation for ‘Memory high threshold violation rate’. |
| Virtual memory size | The total memory allocated to the server. | MB | |
| Active threads | Number of threads from the asynchronous thread pool currently processing user requests. | Number | Reaching the maximum thread pool size means new requests must wait, potentially slowing down processing. Consider increasing the thread pool size if this occurs frequently. |
| Current number of auditing events queued | Indicates the count of auditing events recorded by an auditee that are yet to be retrieved by the CMS Auditor. | Number | An unbounded increase may signal improper auditing configuration or system overload, causing events to be generated faster than retrieval. Before stopping servers, disable them and allow the auditing events queue to clear. Unretrieved events may only be processed upon server restart and CMS polling. |
It’s particularly important to understand the metric “Current number of auditing events queued”. This measurement reflects the backlog of auditing events that have been recorded but not yet processed by the CMS Auditor. A consistently growing queue size can indicate several underlying issues. It might suggest that the auditing system is not configured optimally, potentially missing necessary resources or facing bottlenecks in the retrieval process. Alternatively, a large queue could be a symptom of a heavily loaded system that is generating audit events at a rate faster than the auditor can manage.
Alt text: Call to action button labeled Start Free Trial, encouraging users to explore product capabilities.
Monitoring this metric is essential for maintaining system health. A healthy system should ideally have a consistently low or zero value for the “Current number of auditing events queued”. Spikes or a continuous upward trend warrant investigation into the auditing configuration and overall system load. Addressing these issues promptly ensures that auditing data is processed efficiently and system performance is not compromised by an ever-increasing backlog of audit events. Regularly reviewing this metric as part of the Web Intelligence Server Performance test allows administrators to proactively manage their SAP BOBI environment and ensure smooth operation.
