- What performance improvements you can expect from (upgrading to) JIRA 6.4
- How your instance’s performance might change as it scales
- Suggestions of the best tools for implementing your own performance testing
Watch and share the recorded webinar now!
Q&A top 15 questions
Q1. Any suggestions on how to tweak Apache and Tomcat for increased performance?
A1: There are general guidelines on how to do this. However, there are several suggestions that we are aware of such as: matching the allowed Tomcat threads to the reverse-proxy’s thread number and consider changing to a non-blocking connector in Tomcat. We have a knowledge base article available for Confluence that also applies to JIRA that provides details on using Tomcat’s NIO Connector to improve performance here.
Q2. What hardware configurations do you suggest using?
A2: We have a sizing guide available that is based on the experience we’ve had and continue to have testing large scale JIRA installations. Please note that environment specifics can modify and the sizing guide should be only taken as a guideline, not a hard rule book.
Q3. Do translations of custom fields also have influence on performance?
A3: Translations of custom fields have minor influence. It’s rather the overall number of custom fields vs. translated custom fields that has the most influence on performance.
Q4. At what point (how many users) do you recommend going to a data center solution?
A4: Data Center currently delivers in three key areas:
Concurrent load: This is really dependent on the usage of your JIRA installation and does not necessarily have to do with the amount of users you have. We would first suggest looking at your actual performance first during peak times of the day. If you see your JIRA instance being heavily loaded/stressed at certain times of the days (perhaps commensurate with a drop in server side response times) it’s a pretty strong indication you could benefit from balancing that load across several nodes.
High Availability: Should a node fail, users can be failed over to other nodes in the cluster pool. So if there are unplanned outages you are experiencing at the moment, you may be able to avoid disrupting service by putting Data Center in place.
Disaster Recovery: Data Center 6.4 introduced the only Atlassian supported Disaster Recovery offering, so customers who need to ensure continuity of service for their business-critical JIRA or have a need to comply with a Disaster Recovery Plan now have a way to do so.
If you see challenges in any of the three areas above, it’s probably worthwhile taking advantage of our evaluation licenses. These are available for customers to set up a cluster to understand how they can benefit in their own unique environments.
Q5. Which custom fields have the most performance impact?
A5: Free text custom fields are probably the biggest performance eaters. The smallest performance eaters would be the multi-select custom field.
Q6. Do only active workflows affect performance? Do you have any performance tests against REST API usage?
A6: Workflows that are not in use (inactive) will not have impact on your performance. We don’t have any performance tests against REST API usage at this time.
Q7. Have you tried to use “heavy” JQLs like just searching for a label in all issues?
A7: Absolutely. We run queries like that in our performance lab and they do not cause significant problems.
Q8. The overview of performance tools suggests that there are scripts available for various tools. Do you have any scripts available?
A8: Gatling, one of the tools mentioned in the documentation, allows you to easily record a large number of actions. This will provide you with the option of generating your own scripts. We have decided to not provide scripts at this stage as scripts are usually unique to a customer’s instance and use case.
Q9. Are the number of issues the largest impact on JIRA’s performance?
A9: The number of issues is not actually what has the largest impact on performance in JIRA, especially since 5.1. The amount of custom fields would be an example of something that has a larger effect on performance. For additional details please refer to our scaling JIRA documentation.
Q10. Have you performed any testing with running JIRA in different virtualization technologies?
A10: We haven’t run tests on any virtualization platforms at this time.
Q11. Is there a specific threshold where the number of customer fields starts to effect performance?
A11: Unfortunately there isn’t a magic number, as performance is impacted by many different variables working together at once.
Q12. Is there a recommended frequency that JIRA should be reindexed and/or restarted?
A12: There’s not a recommended frequency, as there are really a plethora of variables that go into this. Front-end monitoring, with something like JMeter, is probably the best route to start to establish the best practice for your environment.
Q13. Is there a Google group (or similar) where JIRA customers discuss performance testing?
A13: We would suggest posting on our community forum Atlassian Answers. Our employees are extremely active in monitoring the questions that come through. Additionally, there is a LinkedIn group called JIRA Performance Tuning – Best Practices and Troubleshooting.
Q14. Have you guys tried running Tomcat standalone with reverse proxy such as Apache? Did you notice any difference?
A14: We did run an experiment with a remote JIRA instance and local nginx that would cache static resources. We received good results but unfortunately didn’t have time to fully evaluate this approach and create official technical guidelines.
Q15. Does the performance increase apply to versions of JIRA hosted on virtual machines (such as instances hosted on Amazon AWS)?
A15: These results are not dependent on blade server or virtual machines.
If you have any additional questions please feel free to leave a comment!