Running JIRA in a Virtualised Environment

Unsurprisingly, JIRA is generally slower in a virtualised environment. As can be seen in the test results below, the amount by which JIRA 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 JIRA 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 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 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.
• Review Timekeeping best practices for Linux guests as not having the correct kernel parameters can cause high CPU usage inside the guest

VMware ESX 3.5

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

VMware ESX 4i

• Under low-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 JIRA 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.

Low-load JIRA

This test performs around 16 requests/second on the JIRA instance. This is not enough to saturate the host CPU time and during the test there is around 60-80% idle time.

Medium-load JIRA

This test tries to perform double the requests/second of the low load test (i.e. approximately 32 requests/second) on the JIRA instance. This is enough load to saturate the available CPU time on a 4 CPU machine.