Documentation for Confluence 2.5.4 - 2.5.8.
Documentation for [Confluence Cloud] and the latest Confluence Server is available too. 
Deploying any application to several thousand users requires care and planning, expecially if those users are going to be relying on the application to get their work done.
Do not try to deploy Confluence immediately to your whole organisation. Instead, roll it out department by department, or project by project.
How Confluence will scale given a particular software and hardware configuration depends very much on how Confluence is likely to be used in your organisation. Launching Confluence to everybody at once may seem like a neat idea, but it also means that any problems you might experience scaling the system up to your entire organisation will hit you all at once, annoy everyone and possibly hurt adoption.
Rolling Confluence out gradually will give you the chance to tune it as you go, resulting in a much more painless experience. There will also be organisational advantages: you can identify those teams or projects who are most likely to be successful 'early adopters', and those teams can experiment with how best a wiki might suit your organisation, and pass on their 'best wiki practices' as usage of Confluence expands.
Because Confluence can be deployed in so many server combinations, we do not currently have guides on the best tuning parameters for each individual server. We will be happy to provide support, however. If you have any tuning parameters that you find particularly useful for Confluence instances, feel free to share them with other Confluence users in the Confluence Community space.
The Java virtual machine is configured with a "maximum heap size" that limits the amount of memory it will consume. If Confluence fills up this maximum heap size it will run out of memory, and start behaving unpredictably. You can keep track of Confluence's memory usage from the System Information screen of the administration console:
This example shows that, at the time of writing, confluence.atlassian.com is using 173MB of an allocated 313MB of heap. (The JVM was configured with a maximum heap size of 450MB, but this information is not available in the graph. The 313MB figure shows that the full 450MB of heap has not yet been needed)
Confluence will need a database connection for each simultaneous user connection to the server. It is also a good idea to have 5-10 connections spare for Confluence internal processes such as backups, re-indexing or daily notification jobs.
Running out of pooled connections will cause the server to slow down as more users are waiting for a connection to be freed before starting their own request, and will eventually cause visible system errors as Confluence times out waiting for a database connection.
If you are using Confluence's internal connection pool, you can increase the number of available connections by modifying the hibernate.c3p0.max_size property in {confluence_home}/confluence-cfg.xml, and restarting Confluence. Make sure you have also configured your database to be able to support that many simultaneous connections.
The Performance Tuning page includes some useful rules of thumb for configuring the sizes of Confluence's internal caches.
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.
