SAP Web Dispatcher Workload Test
The ICM is implemented as an independent process and is started and monitored by the dispatcher. The ICM process uses a pool of worker threads to parallel process the load. This is why, if a sudden/consistent slowdown is noticed in a SAP system’s interactions with the internet, the first place administrators need to check for inconsistencies is this thread pool. The absence of adequate threads in the pool can significantly impair the ICM’s ability to uniformly distribute the request load across threads, thereby causing one/more threads be over-utilized; ultimately, this will result in a slowdown! Besides erratic thread pool usage, the sudden unavailability of the ICM and over-utilization of ICM connections can also cause disturbances in a SAP system’s internet communications. To ensure that such anomalies are promptly captured and corrected, administrators should keep an eye on the accessibility of the ICM, its thread pool usage, and availability of ICM connections. This is where the SAP Web Dispatcher Workload test helps!
This test periodically checks the availability, thread pool usage, and connection utilization of the ICM, and promptly reports the non-availability of the ICM, abnormal usage of worker threads by the ICM, and the over-utilization of ICM connections. This way, the test leads administrators to the probable causes for the breaks / slowness in the communication between the SAP system and the internet.
Note:
This test uses the Command Line program to collect the required metrics.
Target of the test : A SAP Web Dispatcher
Agent deploying the test : An internal agent
Outputs of the test : One set of results for the target SAP Web Dispatcher that is being monitored.
Parameter | Description |
---|---|
Test period |
How often should the test be executed |
Host |
Specify the host for which the test is to be configured. |
Port |
The port number at which the specified host listens. The default is 2375. |
WEB Dispatcher DIR |
Specify the full path to the directory where the target SAP Web Dispatcher is installed. Ensure that the location specified contains the sapwebdisp and wdispmon executables. |
Profile File |
Specify the full path to the profile file with which the target SAP Web Dispatcher was started. The default name of the profile is sapwebdisp.pfl. |
Timeout |
Specify the time for which the eG agent should wait for collecting the required metrics. By default, this is 60 seconds |
Measurement | Description | Measurement Unit | Interpretation | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Status |
Indicates the current operational state of the SAP Web Dispatcher. |
|
The values reported by this measure and their numeric equivalents are available in the table below:
Note: This measure reports the Measure Values listed in the table above while indicating the current operational state of the SAP Web Dispatcher. However, in the graph of this measure, this measure is indicated using only the Numeric Values listed above. |
||||||||
Current threads |
Indicates the total number of threads created from the thread pool of the SAP Web Dispatcher for processing requests. |
Number |
This measure is a good indicator of the load on the SAP Web Dispatcher. |
||||||||
Percentage current threads |
Indicates the ratio of the total number of threads created to the maximum thread setting. |
Percent |
An unusually heavy network load causes the web dispatcher to continue creating threads until the maximum threads setting (icm/max_threads profile parameter) is reached, i.e., the percentage approaches 100. Once the limit is reached, the requests are queued and may be dropped due to queue full or timeouts. If this high thread usage is expected, then the maximum threads setting is low. Each operating system has an upper limit on the absolute maximum number of threads that its process can spawn depending upon its kernel parameters and available stack size. Please refer to kernel parameter documentation for your OS if you want to increase the maximum threads setting beyond the default limit set by your OS. |
||||||||
Used connections |
Indicates the number of currently open connections. |
Number |
The number of simultaneously open connections and their sockets can be deduced from this measure. |
||||||||
Percentage connections used |
Indicates the percentage of currently open connections i.e., the ratio of the number of connections used to the maximum connection setting. |
Percentage |
Each request needs a thread and a connection for processing. If this value is consistently high, it means that there are many requests awaiting further processing. Maximum connections setting (icm/max_conn profile parameter) is further restricted by maximum sockets setting(icm/max_sockets profile parameter) which in turn is further restricted by a corresponding OS setting. The web dispatcher needs 2 sockets per connection. |
||||||||
Requests in queue |
Indicates the number of requests that are awaiting the threads for processing. |
Number |
|
||||||||
Percentage requests in queue |
Indicates the ratio of the number of requests in the queue to the maximum queue setting. |
Percentage |
If this value is consistently high, it is possible that incoming requests are dropped due to insufficient space in the request queue. If this is expected, consider increasing the request queue size using the icm/req_queue_len profile parameter for the web dispatcher. |