JIRA Performance Tests

This article discusses a few different JIRA server configurations and the test results. It is "work in progress" and the article will be updated as more performance tests are run. If you have suggestions for other load scenarios, please leave a comment or contact me per email.

The servers

The performance test system comprises three identical servers having 12 GByte of RAM, two Intel® Core™ i7-920 Quadcore (2.67 GHz) and two Seagate ST31500341AS disk drives with 1500 GByte each. The two CPUs show up as eight cores in the top command, as it is to be expected. OS is a minimal install of Debian Lenny 64bit. Each server is equipped with an extra NIC connected to a private hub so that traffic between these three servers is processed in the fastest possible way, without routing through the standard gateway of the hosting company. This has in fact a significant effect: scp'ing a large file through the private network is about 60 MByte/sec., through the standard gateway it is only 11 MByte/sec.

Databases are MySQL, PostGresQL (in the standard configuration as provided by the Debian installation) and Oracle Developer. Java is installed from Sun's jdk-6u14-linux-x64.bin file.

JIRA is configured with 4096 MByte of heap space and 512 MByte of PermGen space. The periodic index updating has been turned off (xxx add details).

There are also 225 users and 20 projects with 10 components each defined. The issues are randomly distributed between each project/component combination.

Database / network influence

My first question was: should the database run on the same physical server as JIRA or should one use a separate system? The CPU usage of the mysql daemon is small (xxx about 5%) compared to the CPU usage of the Tomcat application server. When running the JMeter test script, the maximum CPU usage (per core) is about 80%, so in theory there should be plenty of capacity left to run MySQL on the same server without affecting the Tomcat performance. But there is a risk of blocking, even though I have a total of 8 cores running on the server.

The database is loaded with 520438 issues, having some ten lines of random text but no additional comments. It is actually important to have real text in the test data because each issue add triggers an update of the Lucene index and it is obvious that the CPU usage is different if real english words are used, compared with either pure random character strings or just a few real english words. Therefore I am using about 2500 unique words from a novel.

The test script is a JMeter test script that will create 10000 additional JIRA issues using 20 threads. It will be run twice, only the second execution time will be measured. Before the tests begin, the database will be loaded with the initial content, the index directory will be deleted and the index will be recreated.

Also the network response time should be better if the packets are routed directly to the MySQL server instead to a switch, another server and back.

Result: The overall performance is better if MySQL runs on a different server, although only by a small margin. When MySQL is running on a separate server, the server load of that system is only 5% to 10%.

Issue creation rate as a function of VM Heap Space

Tomcat runs better when it has more RAM for its heap allocated, but how much? This test runs the "Create Issues" test script for a few different VM configurations.

It turns out that there is not that much of a difference if there are only few issues in JIRA, but for large issue counts a large heap size surely helps.

Create 1 Mio issues

The performance test is based on a JIRA database having 1 Mio. issues. Therefore the first step is to create this amount of issues, a reasonable number of comments then will be added in a next step.

It turned out that the create issue rate really drops fast. I was hoping that this step could be completed in a short time given the initial create issue rate of about 1500 issues per minute, but that was not possible.

Server load is about 5.5 at 750000 issues. The MySQL server load is negligible with about 5%. The sudden performance increase at 750000 issues correlates with a Tomcat server restart.

The diagram shows the number of issues created per minute as a function of the total JIRA issue count.

Workflow actions

The next scenario will be a typical JIRA session: issues are viewed, comments are added, issues are resolved and closed.

Results will be posted here as soon as we have 1 Mio. issues in our DB.

Comparison with WANdisco JIRA cluster

We will then run the same tests on a WANdisco JIRA cluster with 2 and 3 nodes.