Confluence is generally slower in a virtualised environment. As can be seen in the test results below, the amount by which Confluence slows down varies based on the workload.

Under low load there are several operations which are in fact faster under VMware. This is probably due to the 4CPU VM instance running on 8 real CPUs as opposed to there being only 4 real CPUs on the baseline machine.

Please note, no performance tuning was applied to VMware for these tests. It may be possible to improve Confluence's performance by tuning VMWare. However, this may cause other applications to run more slowly on the virtual environment. We recommend that you consult the VMware documentation before deciding whether to do this.

General

• If you are a running a medium-to-high-load instance, your biggest performance gain will be to run the application and database on a real machine and not on virtual infrastructure.
• Under medium-to-high-load, moving the database onto another machine will help.
• Always ensure that there are enough virtual CPUs and memory allocated to the virtual instance. This may not be possible under VMware ESX 3.5 due to limitations of 4 vCPUs per VM.
• Always ensure that there is enough CPU time and memory available on the physical host to service all VMs. Applications should not go into swap.
• Use modern CPUs with VT extensions — there is still a noticeable performance penalty for using a VM with these CPUs, but it will likely be much higher when using old CPUs.
• Carefully monitor your VMware hosts to ensure that there is no resource starvation.

VMware ESX 3.5

• If possible, upgrade to VMware ESX 4i.
• Under low-to-medium-load, using a non-virtualised database will generally result in better response times.

VMware ESX 4i

• Under low-to-medium-load, keep the database inside the virtual machine if there is enough CPU time for both the database and application.
• Using VMware EX 4i and virtual machine version 7, you will be able to allocate up to 8 vCPUs to an instance.

Server Configuration

All testing was performed on the following hardware. In the case of virtual machines, one VM per machine was configured.

Notes:

1. VT extensions were enabled in the BIOS on the machines running VMWare.
2. VT extensions were disabled in the BIOS on the machines not running VMWare, as per Dell best practices.
3. In order to limit the CPUs in the baseline test to match the number in VMWare, the kernel boot parameter maxcpus=4 was added to the startup.
4. The full disk was allocated to VMware.
5. The filesystem used in all machines was EXT3.

Installed Software

Each server was set up with identical software, as follows:

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 1310720000
kernel.shmall = 4294967296
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4098 65536 16777216
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.netdev_max_backlog = 2500

Testing Tool

Performance tests were conducted with Apache Jakarta JMeter 2.3.4 using the standard Confluence performance tests.

The following tests were performed for each application. In each case, the test was performed with a database local to the host instance (i.e. in the same operating system image) and also with the database residing on a separate, non-virtualised physical server of the same specifications as above.

Result Descriptions

The following descriptions relate to the result graphs below.

• Average time Comparison — The average response time of the requests in the scenario - the lower the better.
• 95 percent Comparison — The time (in milliseconds) by which 95% of all requests in the scenario have completed. This is not an average value – rather, you can think of it as a 'how long the slowest requests (except the very worst 5% cases) take to complete' scenario.
• Scenarios:
  • Dashboard — Simulates visiting the Confluence dashboard.
  • Edit Page — Simulates saving a page back to Confluence and notifying all people who are watching this page.
  • View Page — Simulates loading one out of hundreds of different Confluence pages. Some are short, others are long. Some have many images, others have many comments. Some have many macros, others do not. The pages are accessed through their full URL, as if someone had clicked a link within the application or a bookmark.
  • Search Site — Simulates a search across the whole system.
  • Browse User Personal Space — Simulates regular browsing of pages in a user's personal space.
• Ext-DB (In the legend of each graph) — Indicates scenarios in which the database resides on a separate, non-virtualised physical server.

Low-to-Medium-load Confluence

This test performs around 18 requests/second on the Confluence instance. This is not enough to saturate the host CPU time and during the test there is around 50-75% idle time. You could expect to see similar results if your Confluence instance has enough resources available to it.

Medium-to-High-load Confluence

This test tries to perform double the requests/second of the lower load test (i.e. approximately 36 requests/second) on the Confluence instance. This is enough load to saturate the available CPU time on a 4 CPU machine. This test is designed to simulate an instance which does not have enough resources to serve the number of requests being made to it.