nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Custom fields and Jira Performance

MEDITECH ADMIN TEAM

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.

Accepted answers

Chris Solgat

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.

All comments

Chris Solgat

MEDITECH ADMIN TEAM

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.

MEDITECH ADMIN TEAM

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.

Myra_Rebillard

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!

Josh Simnitt

Myra:

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.

https://confluence.atlassian.com/enterprise/managing-custom-fields-in-jira-effectively-945523781.html

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.

roman smatana

Hello,

just one point.... creating custom field with default value and global context is IMHO bad idea as every new issue is created with that default value.

I found on our instance one such text field with almost 1kb template as default value. It was Created 2 years ago, it generated 200k values, mostly default values - not seen on screens.

Imho : index can suffer with such field values, the best remedy is to find out which values are critical, migrate them to new field, narrow the scope, and delete original field.

Before doing any change with fields, inform affected projects of course :-).

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

custom-field

jira

jira-software

jira-administration