eG Monitoring
 

Measures reported by ConfluRStatsTest

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.

Outputs of the test : One set of results for the target Atlassian Confluence server

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
currentReq Indicates the number of requests currently being served by Confluence Number This is a good indicator of the current workload of Confluence.
errorCount 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.

reqserved Indicates the number of requests served Number  
averExeTime 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:

  • Use the latest versions of your application servers and Java runtime environments. Newer versions are usually better optimized for performance.
  • Always watch the swapping activity of your server. If there is not enough RAM available, your server may start swapping out some of Confluence's heap data to your hard disk. This will slow down the JVM's garbage collection considerably and affect Confluence's performance. In clustered installations, swapping can lead to a Cluster Panic due to Performance Problems. This is because swapping causes the JVM to pause during Garbage Collection, which in turn can break the inter-node communication required to keep the clustered nodes in sync.
  • Be aware of other systems using the same infrastructure. Because, one application's bug might start affecting other applications. Either make sure applications can't harm each other despite sharing the same infrastructure, or get these systems untangled, for example by moving them to separate instances that can be controlled better.
  • The embedded H2 database is provided for evaluating Confluence, not for production Confluence sites. After the evaluation finishes, you must switch to a supported external database.
  • If load on Confluence is high, you may need more simultaneous connections to the database. If you are using JNDI data-sources, you will do this in your application server's configuration files. If you have configured Confluence to access the database directly, you will need to manually edit the hibernate.c3p0.max_size property in the confluence.cfg.xml file in your confluence.home directory. After you have changed the URL in this file, restart Confluence.To assess whether you need to tune your database connection pool, take thread dumps during different times (including peak usage). Inspect how many threads have concurrent database connections.
  • To reduce the load on the database, and speed up many operations, Confluence keeps its own cache of data. Tuning the size of this cache may speed up Confluence (if the caches are too small), or reduce memory (if the caches are too big).
  • Antivirus software greatly decreases the performance of Confluence. Antivirus software that intercepts access to the hard disk is particularly detrimental, and may even cause errors with Confluence. You should configure your antivirus software to ignore the Confluence home directory, its index directory and any database-related directories.
  • If bandwidth is responsible for bottlenecking in your Confluence installation, you should consider enabling HTTP compression. This may also be useful when running an external facing instance to reduce your bandwidth costs. Take note of the known issues with HTTP compression in versions of Confluence prior to 2.8, which may result in high memory consumption.
  • For high-load environments, performance can be improved by using a web server such as Apache in front of the application server. When configuring your new web server, make sure you configure sufficient threads/processes to handle the load. This applies to both the web server and the application server connector, which are typically configured separately. If possible, you should enable connection pooling in your web server connections to the application server.
  • Some external plugins, usually ones that have been written a long time ago and that are not actively maintained anymore, have been reported to consume memory and never return it. Ultimately this can lead to a crash, but first this manifests as reduced performance.
  • If Confluence is running slowly, one of the most likely cause is that there is some kind of bottleneck in (or around) the database. Check the value of the databaseExpLatency measure to determine whether/not you are dealing with a latent database. Then, take some database optimization measures to improve database performance. which in turn will improve the performance of Confluence.
databaseExpLatency 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.