Confluence 4.0 : Configuring a Large Confluence Installation
This page last changed on Feb 23, 2011 by smaddox.
Deploying any application to several thousand users requires care and planning, especially if those users are going to be relying on the application to get their work done. General AdviceStaged RolloutDo 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. Plugin GovernanceConfluence plugins can add tremendous value. Before adding one, visit the plugin's page and explore its issues (available from the issue management link). Try the plugin in a test environment and make sure to note any adverse effects after adding it to a production environment. Test plugins independently when upgrading. Backup strategyDisable the XML backup and use the Production Backup Strategy. New Spaces GovernanceFor both performance and good practice, put some modest governance in place around the creation of new spaces, such as a simple request that includes a check for duplicates and some strategy around how to best use a space. Duplicates and unused spaces should be purged by a wiki gardener. Try to keep it to one space per group. Choosing User Management and Single Sign-OnWe recommend that you choose and configure your user management solution as soon as possible, rather than adding it to your Confluence installation at a later date. It is possible to integrate with an LDAP repository, such as Microsoft Active Directory, or add a single sign-on solution later (especially with the addition of Crowd). But if possible it is best to configure your user management system up front. You can configure access for only a specific group or set of groups, thereby keeping the gradual rollout. Please refer to our detailed guide to Configuring User Directories and examine the User Management Limitations and Recommendations. Configuring your Application Server, Web Server and DatabaseBecause 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. Best PracticesTroubleshooting possible memory leaksThe 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. Many of the issues reported there are exacerbated with a large installation. Memory UsageThe 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) Database Connection PoolConfluence 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 Cache SizesThe Performance Tuning page includes some useful rules of thumb for configuring the sizes of Confluence's internal caches. RELATED TOPICSOperating Large or Mission-Critical Confluence Installations |
![]() |
Document generated by Confluence on Sep 19, 2011 02:39 |