Performance Tuning
This document describes tuning your application for improved performance. It is not a guide to troubleshooting Confluence outages. Check Troubleshooting Confluence hanging or crashing for help if Confluence is crashing.
Like any server application, Confluence may require some tuning as it is put under heavier use. We do our best to make sure Confluence performs well under a wide variety of circumstances, but there's no single configuration that is best for everyone's environment and usage patterns.
If you are having problems with the performance of Confluence and need our help resolving them, you should read Requesting Performance Support.
Performance Data Collector
See How to use the Performance Data Collector for more information.
On this page:
Use the latest version of your tools
Use the latest versions of your application servers and Java runtime environments. Newer versions are usually better optimized for performance.
Avoid swapping due to not enough RAM
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.
Being aware of other systems using the same infrastructure
It may sound tempting: Just have one powerful server hosting your database and/or application server, and run all your crucial programs on that server. If the system is set up perfectly, then you might be fine. Chances are however that you are missing something, and then one application's bug might start affecting other applications. So if Confluence is slow every day around noon, then maybe this is because another application is using the shared database to generate complicated reports at that time? 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.
Choice of database
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. We recommend using what you are familiar with, because your ability to maintain the database will probably make far more difference to what you get out of it than the choice of database itself.
Database connection pool
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.
Database in general
If Confluence is running slowly, one of the most likely cause is that there is some kind of bottleneck in (or around) the database.
The first item you should check is the "Database Latency" field in the System Information tab in the admin console. 
The latency is calculated by sending a trivial request to the database, querying a table which is known to have only one column and one row. ("select * from CLUSTERSAFETY"). Obviously this query should be blazing fast, and return 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 something! A few milliseconds may not sound so bad, but consider that Confluence sends quite a few database queries per page request, and those queries are a lot more complex too! 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.
Obviously, latency is just the very first thing to look at. 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.
Database statistics and query analyzers
Modern databases have query optimizers based on collecting statistics on the current data. Using the SQL EXPLAIN statement will provide you information on how well the query optimizer is performing. If the cost estimate is wildly inaccurate then you will need to run statistics collection on the database. The exact command will depend on your database and version. In most cases you can run statistics collection while Confluence is running, but due to the increased load on the database it's best to do this after normal hours or on a week-end.
Cache tuning in Confluence and Apache
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).
Please have a look at our documentation on Cache Performance Tuning for information on how to tune Confluence caches.
Antivirus software
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.
Enabling HTTP compression
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.
Performance testing
You should try out all configuration changes on a demo system. Ideally, you should run and customize loadtests that simulate user behavior.
Access logs
You can find out which pages are slow and which users are accessing them by enabling Confluence's built-in access logging.
Built-in profiler
You can identify the cause of page delays using Confluence's built-in profiler according to Troubleshooting Slow Performance Using Page Request Profiling.
Application server memory settings
See Fix java.lang.OutOfMemoryError in Confluence.
Web server configuration
For high-load environments, performance can be improved by using a web server such as Apache in front of the application server. There is a configuration guide to Running Confluence behind Apache.
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.
Troubleshooting possible memory leaks
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. The Troubleshooting Confluence hanging or crashing guide is a good place to start. Some of the known causes listed there could result in performance issues short of a crash or hang.