Trex WorkLoad Test
Workload analysis for a SAP TREX server involves:
- Determining the number of search requests, indexing requests, index merging requests serviced per minute;
- Understanding the time spent to service the search requests, indexing requests, merging requests etc;
- Knowing how well the index server is processing the requests;
- Determining how well the memory of each component of the SAP TREX (RFC server, Index server, Queue server) is utilized.
This not only reveals the current workload of the SAP TREX server, but also highlights the processing ability of the SAP TREX server, pinpoints bottlenecks in processing, and leads administrators to where these bottlenecks lie. To perform such detailed workload analysis, administrators can use the Trex Workload test.
This test reports the current CPU and disk space usage of the server to indicate its current load. In addition, the test reveals the number of search requests, indexing requests and merging requests that the server processes every second, so that administrators can understand how well the server handles the load and can accurately identify where bottlenecks lie. By comparing the CPU usage of the server with its processing ability, administrators can intelligently figure out if the server requires additional CPU resources for improved performance.
Target of the test : A SAP TREX
Agent deploying the test : An internal agent
Outputs of the test : One set of results for the SAP TREX server that is to be monitored
| Parameter | Description |
|---|---|
|
Test Period |
How often should the test be executed |
|
Host |
The host for which the test is to be configured. |
|
Port |
Specify the port at which the specified host listens. By default, this is 30001. |
|
WSDLPort |
This test uses the SAPControl web service to pull metrics on application and service status. To enable the test to communicate with the web service, you need to configure the test with the port number of the web service. Therefore, specify the port number of the SAPControl web service against WSDL PORT. To determine the exact port number of the SAPControl web service, you can look up the etc/services file on the SAP TREX being monitored. If the port number is not declared in the etc/services file, you can specify the default port number of the web service against WSDL PORT. If the web service is not SSL-enabled, then the default port number of the web service will be: 5<NR>13. Similarly, if the web service is SSL-enabled, then the default port number of the web service will be: 5<NR>14. <NR> in the port number refers to the system number of the SAP TREX server being monitored. The system number is an indicator of the TCP/IP port at which the SAP TREX server listens. For example, for a server that listens at port 3200, the system number will be ‘00’. Similarly, if the SAP server port is 3201, the system number will have to be specified as ‘01’. Accordingly, the default port number of an SSL-enabled SAPControl web service will be 50014 , if the system number is 00, or 50114, if the system number is 01. |
|
SSL |
Set this flag to Yes, if the SAPControl web service is SSL-enabled. Set this flag to No, if the SAPControl web service is not SSL-enabled. |
| Measurement | Description | Measurement Unit | Interpretation |
|---|---|---|---|
|
Search rate: |
Indicates the number of search requests per minute. |
Requests/min |
This measure is a good indicator of the load on the TREX server. The load on the server is directly proportional to the search time. |
|
Indexing rate: |
Indicates the number of indexing requests per minute. |
Requests/minute |
A low value is desired for this measure as frequent indexing may affect the performance of the TREX server. |
|
Merge rate: |
Indicates the number of requests received to merge the delta indexes to the corresponding main indexes per minute. |
Requests/minute |
Merging or integration of delta indices with main indices needs to be scheduled with consideration. It involves rewriting of all main index files. Duration can be from a few minutes to several hours. During the merge, the index server cannot index new documents and hence indexing requests have to wait until such time. For such reasons merges are not scheduled during business hours and only if the delta index reaches a certain size. Due to the performance impact of merging, the merge requests rate needs to be monitored and configuration changes can be made to reduce merging as needed. |
|
Unload rate: |
Indicates the number of requests received to unload the index attributes from the memory per minute. |
Requests/minute |
Index attributes can be preloaded into memory for faster index performance. However, too many indexes preloaded into memory may cause free memory shortage resulting in unload requests to unload attributes of some indexes. An increasing unload rate is a clear indicator of memory issues in TREX. In such case, either the memory can be increased or index preloading can be reduced. Too many unloads is said to lead to server instability issues. |
|
Search time: |
Indicates the amount of time spent per minute to service the search requests. |
Milliseconds/minute |
When compared with search rate this measure tells us whether any increased search time is simply due to increased search requests or due to slowness in the search performance |
|
Index time: |
Indicates the amount of time spent per minute to index the documents/data in the index server. |
Milliseconds/minute |
When compared with index rate this measure tells us whether any increased index time is simply due to increased index requests or due to slowness in the indexing. During times of increased merge activity, indexing time will also suffer as the indexing may have to wait till the merging is done for the indices. |
|
Merge time: |
Indicates the amount of time spent to merge the delta indexes with the corresponding main indexes |
Milliseconds/.minute |
When compared with merge rate this measure tells us whether any increased merge time is simply due to increased merge requests or due to slowness in the merge. Typically merges are configured when the delta index size reaches 500 mb. Apart from delta index size, merge time is also proportional to the main index size. |
|
Index server ping time: |
Indicates the time taken by the index server to respond to requests. |
Milliseconds |
Unlike a standard TCP ping, this measurement corresponds to the time taken by the index server to respond to a watchdog service, typically, the nameserver. Correspondingly, this time depends upon the load on the index server. |
|
Index server threads: |
Indicates the number of threads instantiated on the index server. |
Number |
|
|
Index server handles: |
Indicates the number of handles generated and used by the index server. |
Number |
This includes the number of open files, sockets and other unknown handles. |
|
Index server memory: |
Indicates the amount of memory used by the index server to process the requests. |
GB |
If the index server is consuming high memory you can optimize the settings in TREXIndexServer.ini file. You can limit the max result set size for queries and parallel query execution. You can also consider turning off index statistics and index usage collection and using caches and compression. |
|
Queue server memory: |
Indicates the amount of memory used by the queue server. |
GB |
|
|
RFC server memory: |
Indicates the amount of memory used by the RFC server. |
GB |
If this memory usage is high and you have many RFC servers running in single thread mode, consider switching to multi-thread mode to reduce the memory consumption |
|
Overall memory: |
Indicates the overall memory utilized by the TREX server. |
GB |
|
|
Disk space used: |
Indicates the disk space utilized by the TREX server. |
GB |
|
|
CPU used: |
Indicates the percentage of CPU utilized by the TREX server. |
Percent |
|
