What customizations slow down JIRA the most?

John Shoemaker

I inherited a JIRA instance that, for about 2 years, gave everyone admin permissions and they went crazy! Custom everything! I have been slowly cleaning up and consolidation, but the low hanging fruit has run out. I need to know where to best focus my energy as the remaining tasks require a lot more analysis, coordination, and are harder to implement. My question is, where should I focus my efforts to make the biggest impact? Workflows, Statuses, Resolutions, Fields, Screens, Projects, Issues, Issue Types, etc. Are any one of these more important than others (from a performance perspective) or are they all equally weighted? Thanks

 

PS. I should mention that I am currently using Cloud and about to self-host.

Andy Heinzer

In my opinion, the answer to your question can be different depending on the platform/product you are currently using.  I'll try to explain what I mean.

 

In Jira Server and Jira data center, your data in Jira is being indexed by Lucene from a SQL database that you host.   Creating and updating those indexes can be a rather intensive process if you have a large instance with lots of issues and lots of custom fields.  This is because Jira is doing a SQL lookup for all the global custom fields per all the Issues in Jira.   If you have 100,000 issues in Jira and 300 custom fields, that's 30,000,000 lookups that have to happen. Even if most of the issues are NULL or have no value for some fields, there is still overhead on the system to correctly update/populate those index values.  

In some cases, Jira data center can amplify a problem like this because each node in a data center deployment could be making the same requests of your SQL server concurrently.   So I think data center deployments tend to suffer a bit more performance bottlenecks in regards to SQL performance in general simply because of the design difference to a single node Jira Server installation.

 

But in regard to indexing, it's not exactly the same for Jira Cloud anymore.  Cloud isn't using the exact same indexing process as it once was in server.   I have not found a lot of documentation about this change publicly, but there are others that have noticed this and have referenced other blog posts about the changes such as in https://community.atlassian.com/t5/Jira-questions/JIRA-CLOUD-indexing-missing/qaq-p/614235

It's harder for me to say for sure where would be best to focus in Jira Cloud.

However if you are planning to go to Jira Server, then I would recommend checking out the Jira Sizing Guide.  It takes into account the size of your Jira data set, in terms of issues, issues per month, active users, custom fields, projects, workflows, schemes etc, and then tries to give you more information on how much system resources you should be allocating to the server and to Jira's JVM in order to get good performance out of the product.

In general, when Jira admins are wanting to clean up a system in order to try to improve performance, I usually see number of issues and/or number of global custom fields tend to be the data that can grow out of control in some cases.  But in addition to that, plugins to Jira can also be a source of significant overhead that isn't typically accounted for in guides like the one I cited above.  Some plugins are not very intensive.  But when it comes to Jira Server, plugins tend to be loaded directly in the same JVM as Jira is, and some of them can impose additional overhead depending on their functionality and complexity.