JIRA performance metrics

Performance is expected in business software, and this page documents the findings from our performance testing for this release of  JIRA 7.2 . Our aim is to improve, or at the very least maintain, key performance metrics with each release of JIRA. We'll detail the key findings, and then give you some details on what test environments we used.

Key findings

We looked at three key areas when testing performance, and we've summarized the results, along with graphs of our measurements.

The dashboard

Our finding indicate that for large instances, the performance of the dashboard on a JIRA Software 7.2 instance will improve. The improvements on server response times and throughput will increase stability and reduce error rates.

Performance Graph
Dashboard average response times - JIRA Software 7.2 server response times for the dashboard are marginally faster than for JIRA 6.4. That means that a JIRA Software 7.2 server responds quicker to a request for the dashboard from a web server than a JIRA 6.4 server.
  Show me the numbers

Dashboard throughput - A JIRA Software 7.2 server's ability to handle throughput increases its stability and reliability under load. That means that a JIRA Software 7.2 server is able to deal with multiple users simultaneously requesting the dashboard with less errors.
  Show me the numbers

The numbers for these charts were generated on a JIRA instance under very high load with up to 1200 concurrent threads running i.e. there are a lot of users logged in and using JIRA.

 Fig. 1 shows that JIRA Software 7.2 is capable of handling roughly 20 concurrent calls per second. There is some noise here from the increase in the number of async calls being made in 7.2, these increase load and cause changes in the number of calls that can be handled per second.

 

Fig. 2 shows the average response time. There's a significant change here between JIRA 6.4 and JIRA Software 7.2. It looks like JIRA Software 7.2 is taking longer to respond as load on the system grows, whereas response times for 6.4 remain relatively flat. What actually happens is up to 200 threads the results are very similar, once we get past 200 concurrent threads JIRA 6.4 error rates increase dramatically, which significantly affects the 6.4 results and makes them unreliable (requests fail and are not measured). Fig3 shows that as load increases JIRA Software 7.2 is still capable of responding without throwing errors and exceptions, whereas JIRA 6.4 generates errors, which result in no dashboard being displayed.

 

Fig. 1

Fig. 2

Fig. 3

Dashboard page load times - JIRA Software 7.2 dashboard page load times are slightly slower (around 650ms) than JIRA 6.4. This will only really be noticeable on small instances where the amount of data and load are not the main cause of performance bottlenecks.
  Show me the numbers

The green readyForUser line which tells us when a page is ready for the user to interact with it.

View issue

Our finding indicate that for large instances, the performance of view issue (i.e. a request made to view the issue page by a user clicking an issue link) on a JIRA Software 7.2 instance will improve. The improvements on server response times and throughput will also increase stability and reduce error rates. Of note is the readyForUser page load time, as seen in Fig. 3 in the View issue page load times section. This means that in JIRA Software 7.2, the view issue page will load quicker and allow a user to interact with it sooner than in JIRA 6.4.

Performance Graph
View issue average response times - JIRA Software 7.2 server response times for the dashboard are significantly and consistently faster than for JIRA 6.4. That means that a JIRA Software 7.2 server responds quicker to a request from the web server than a JIRA 6.4 server.
  Show me the numbers

View issue throughput - A JIRA Software 7.2 server's ability to handle throughput increases its stability and reliability under load. That means that a JIRA Software 7.2 server is able to deal with multiple users simultaneous requests.
  Show me the numbers

The numbers for these charts were generated on a JIRA instance under very high load with up to 1200 concurrent threads running i.e. there are a lot of users logged in and using JIRA.

The results here are similar to the dashboard results. Fig. 1 shows that JIRA Software 7.2 is capable of handling roughly 20 concurrent calls per second. Again, there is some noise here from the increase in async calls being made in 7.2, these increase load and cause changes in the number of calls that can be handled per second. 

Fig. 2 shows the average response time, and again there's a significant change here between JIRA 6.4 and JIRA Software 7.2. We have the same results that seem to indicate JIRA Software 7.2 is slower, whereas what's actually happening is JIRA 6.4 is throwing errors and failing to respond in some cases, as can be seen in Fig. 3. JIRA Software 7.2 is completing each request and showing 0 errors.

Fig. 1

Fig. 2

Fig. 2

View issue page load times - JIRA Software 7.2 will load the view issue page faster than JIRA 6.4. This means users can interact with the issue and JIRA sooner.
  Show me the numbers

The green readyForUser line which tells us when a page is ready for the user to interact with it.

Issue search

In general, the issue search results indicate that the issue search page in JIRA Software 7.2 will load marginally slower (around 500ms) than in JIRA 6.4. However, as in the previous results, the number of potential errors under load has significantly decreased, meaning JIRA is responding correctly for more users performing an issue search, defined as a JQL search request performed via the issue navigator.

Performance Graph
Issue search average response times - JIRA Software 7.2 server response times for issue search are slower than for JIRA 6.4. That means that a JIRA Software 7.2 server responds slower to a JQL request from the issue navigator submitted by the web server.
  Show me the numbers

Issue search throughput - A JIRA Software 7.2 server's ability to handle throughput increases its stability and reliability under load. That means that a JIRA Software 7.2 server is able to deal with multiple users simultaneously performing searches with less errors.
  Show me the numbers

The numbers for these charts were generated on a JIRA instance under very high load with up to 1200 concurrent threads running i.e. there are a lot of users logged in and using JIRA.

The results here are similar to the results for the dashboard and view issue. Fig. 1 shows that JIRA Software 7.2 is capable of handling roughly 20 concurrent calls per second. Again, there is some noise here from the increase in async calls being made in 7.2, these increase load and cause changes in the number of calls that can be handled per second. 

Fig. 2 shows the average response time, and again there's a significant change here between JIRA 6.4 and JIRA Software 7.2. We have the same results that seem to indicate JIRA Software 7.2 is slower, whereas what's actually happening is JIRA 6.4 is throwing errors and failing to respond in some cases, as can be seen in Fig. 3. JIRA Software 7.2 is completing most request until 1025 concurrent threads are run, and then starts to throw errors, though still less than JIRA 6.4.

Fig. 1

Fig. 2

Fig. 3

Issue search page load times - JIRA Software 7.2 dashboard page load times are slightly slower (around 500ms) than JIRA 6.4. This will only really be noticeable on small instances where the amount of data and load are not the main cause of performance bottlenecks.
  Show me the numbers

The green readyForUser line which tells us when a page is ready for the user to interact with it.

Hardware, software and test setup

Knowing how we tested JIRA is important to understand the characteristics of JIRA's performance, and will give you a better feel of how these changes will affect your instance. We tested an instance of JIRA Software 7.2 against an instance of JIRA 6.4.13 and JIRA Agile 6.7. We installed these instances on identical hardware, and loaded the same datasets.

  Hardware

Response test

Bamboo hardware

CPU: 2x 2.4 GHz Intel Xeon® E5-2676 v3 (Haswell) processors

RAM: 8 GB

Throughput test

  Details How it was configured
Hosts The server that's running JIRA.

6 AWS m4.xlarge instances ( 4x2.4 GHz Intel Xeon® E5-2676 v3 (Haswell) processors, optimized network, running in Frankfurt in the same AZ eu-central-1b)

JIRA, Database and jmeter client are running on separate hosts

Database The database used to store the data. MYSQL 5.5, max_allowed_packet      = 256M
Tomcat The web server accepting requests from the clients. maxThreads="50", minSpareThreads="25", acceptCount="1000"
JIRA How we configured JIRA.

Xmx set to 4GB

Max db connections 200

  Data set

This the data set we used to perform our tests. You can check your own instances data statistics via  > System > System Info > Database Statistics.

JIRA Configuration Item Value
Issues 700,000
Projects 850
Custom Fields 820
Workflows 225
Attachments 465,000
Comments 1,500,000
Agile Boards 1,000
Users 43,000
Groups 4,100
Security Levels 19
Permissions 37
  Testing

Our performance tests were all run on the same controlled isolated lab at Atlassian. For each test, the entire environment was reset and rebuilt, and then each test started with some idle cycles to warm up instance caches. We ran jmeter tests and increased the number of threads from 0 to around 1500 for 6 hours. The jmeter memory was set to 12GB.

Each thread was executing the following loop:

  • Dashboard page 
  • Issue search UI (first requests)  resolution is EMPTY ORDER BY createdDate
  • Issue search REST resolution is EMPTY ORDER BY createdDate
  • Issue search REST assignee=admin
  • Issue search REST resolution is EMPTY ORDER BY createdDate

  • Create comment REST with 743 characters
  • View issue page
  • Agile work page
    • In 7.2 this request also embeds Agile work config
  • Agile work REST
  • Agile work REST

Please note that this loop results in substantially more tasks than would be possible by a real user, and you should not equate the number of threads as being equal to real world concurrent users.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport