Custom fields and Jira Performance

How specifically do custom fields affect performance? If they are configured as being available for all projects and issue types will they be evaluated each time we view and issue even though they were never placed on the screen and hence will never have a value? Does carefully restricting the issue types and projects that a custom field is configured for mitigate performance concerns to some extent? I noticed when doing a simple api call to get an issue it does appear to evaluate all the custom fields that the issue type and project is eligible for even if the custom field is not on any screen for that particular issue.

Before reviewing our custom field setup I was hoping to get a better understanding of exactly what it is about the custom field that makes it cause performance issues. We are only at about 250 custom fields so not a huge number but would like to ensure we do not put ourselves in a bad position.

2 answers

1 accepted

2 votes
Accepted answer

The short answer is, yes, every field will exist on every issue inside every project and issue type.  You can attempt to manage this through contexts and field configurations, but may end up spending more time and effort than what it's worth.  It may also have some unintended consequences if there are no Global Contexts for a field.  In my experience, it has caused problems when you want to copy/clone an issue between projects or when moving an issue between projects.

The best answer is, make a plan for when to create a new field and stick to it.  Attempting some type of Project Templates is one of the best methods I've seen.  I've seen a good rule of thumb for creating new fields is an 80/20 rule.  If 80% of the user/project base could reasonably use the new field, create it.  If it falls under the 20%, either try and come up with a different option, or get them to agree to a more "generic" field that could fall into the 80%.

There is no silver bullet to solve this, but it is very important in regards to system performance.  When Atlassian first released their performance test results, the number of custom fields was the Number 1 contributor to performance degradation.  Take it from someone working on an instance with over 300 projects, 800,000 issues and 2,000 custom fields, figure it out now, before it gets out of control.

I have a support ticket opened with Atlassian looking for a more detailed answer as to how the restrictions applied to a custom field impact JIRA indexing and JQL search speeds. Additionally, I pointed out to them that when making a REST API call (api/2/issue/{issuekey} it will return ALL fields for which that issue is eligible for. This makes me believe it is rather important to configure the custom fields such that they only pertain to the specific projects and or issue types they will be used on. Atlassian submitted JRA-63338 which leads me to believe their is in fact a problem with how the rest service functions and that how you configure your custom fields will significantly impact performance.

Hi there - can you please share what they gave you as an answer to your question?  I am in the same boat.  Our instance is not quite like Chris's, but it's definitely getting up there.  We have about 1200 custom fields. 

I just finished doing a massive 'clean-up' of unwanted customfieldvalue entries.  These were created from customfields given a global context and default values.  This contributed to about 4M unnecessary entries.  So for all of those that have default values, I've changed their context to be project and issuetype specific.  But I still need to figure out if this is the way to go for all other custom fields with global contexts.

Many thanks in advance!


I'm not sure if you have seen this page, but it has a little more information.  It appears that limiting the field context will make it run more efficiently. 

Limiting custom field scope

For any custom fields that can't be removed or merged safely, you can limit their scope to the context of specific projects. This helps by:

  • Reducing the index size (Jira Data Center search indexing),
  • Lowering computation complexity, and
  • Reducing the work done by other nodes in the cluster during replication.  

It does feel like somewhat of a trade off. Managing these custom fields via project and issue type restrictions versus the administrative overhead of doing so. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,110 views 4 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you