Request Statistics Test
How quickly Confluence responds to user requests determines how happy users are with the application. If Confluence takes too long to respond to requests, it could point to issues in configuration or tuning that is probably impacting overall server performance. If these issues are not detected promptly and addressed immediately, they may significantly degrade user experience with Confluence.
To avoid this, administrators should run the ConfluRStatsTest at frequent intervals. This test tracks requests to Confluence and reports the time taken by Confluence to service the requests. In the process, the test reveals request processing bottlenecks in Confluence and its overall health. The test also captures and reports errors in processing, thus enabling administrators to promptly intervene and fix the errors. Additionally, the test also runs a sample query on the Confluence database, reports the time taken for the query to run, and thus points to any latency in database connectivity, so that administrators can figure out if that could be impacting the performance of Confluence.
Target of the test: Atlassian Confluence
Agent deploying the test : An internal/remote agent
Outputs of the test : One set of results for the target Confluence server
Parameter | Description |
Test period |
How often should the test be executed |
Host |
The host for which the test is to be configured. |
Port |
The port number at which the specified host listens to |
JMX remote port |
Here, specify the port at which the JMX listens for requests from remote hosts. Ensure that you specify the same port that you configured in the catalina.bat file in the <<ATLASSIAN_CONFLUENCE_INSTALL_DIR>>\confluence\bin directory. |
JNDIname |
The JNDIname is a lookup name for connecting to the JMX connector. By default, this is jmxrmi. If you have resgistered the JMX connector in the RMI registry using a different lookup name, then you can change this default value to reflect the same. |
JMX Registry SSL |
If you have registered the JMX connector in an SSL-enabled RMI registry , set this flag to Yes. By default, this is set to No. |
User, Password, and Confirm password |
If JMX requires authentication only (but no security), then ensure that the user and password parameters are configured with the credentials of a user with read-write access to JMX. Confirm the password by retyping it in the Confirm Password text box. |
Timeout |
Specify the duration (in seconds) for which this test should wait for a response from the target server. If there is no response from the target beyond the configured duration, the test will timeout. By default, this is set to 10 seconds. |
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Current number of requests being served |
Indicates the number of requests currently being served by Confluence. |
Number |
This is a good indicator of the current workload of Confluence. |
Number of error pages served |
Indicates the number of times the Confluence error page was served. |
Number |
Ideally, the value of this measure should be 0. A non-zero value indicates errors in processing. |
Number of requests served |
Indicates the number of requests served. |
Number |
|
Average execution time of last 10 requests |
Indicates the average execution time for the last ten requests. |
Msecs |
Ideally, the value of this measure should be low. If this value keeps increasing consistently, it could indicate poor server performance. To avoid this, make sure that the following are in place:
|
Database example latency |
Indicates time it took for the database to execute the sample query. |
Msecs |
Ideally, the value of this measure should be very less. A high value is indicative of database problems. Typically, the sample query used should return results within 1 or 2 milliseconds. If the value displayed is between 3 and 5 milliseconds, you might already have an issue. If the value is above 10ms, then you definitely need to investigate and improve performance! High latency might stem from all sorts of problems (slow network, slow database, connection-pool contention, etc), so it's up to you to investigate. Don't stop improving until latency is below 2ms on average. Also, note that you may get zero latency and still have massive database problems, e.g. if your tables are poorly indexed. So don't let a low latency fool you either. |