How to use Jira's Custom Field Optimizer to improve system performance

Jira 7.12 introduced the Custom Field Optimizer for Jira Data Center which has brought Custom Field Contexts to the forefront. Unfortunately, Atlassian's documentation is not clear on the impact of restricting custom field contexts from Global to Project or Issue Type based. This article seeks to clarify why this is important. 

What is the Custom Field Optimizer?

Custom Fields Optimizer is a feature in Jira 7.12 (Data Center) that scans all custom fields and allows you to automatically improve the configuration of them.

Here is an example scan for fields to optimize:

Note that the Custom Fields Optimizer has detected that these fields are not used by any projects. Looking at the fields more closely, they have been placed on screens and attached to projects, but these projects have no issues in them and thus the fields have no real use.

Why should I use it?

The Custom Field Optimizer makes it easy for Jira administrators to configure new custom fields. By default, these custom fields are available for use by all projects in the system: this is called a "Global Context". As the number of custom fields with global contexts grow, every issue in the system must load that custom field on every view or update - even if the field is not relevant to the project, has not been added to the project screen, used in its workflow, or used in some other way related to a plugin or automation. 

Large numbers of custom fields with global contexts have a significant impact on system performance. Not only do they contribute to poor project performance, but can cause dashboards, issue search filters and Kanban boards to be slow.  

Evaluating the impact of an excessive number of custom fields with global contexts
In a recent Jira 7.13 performance test, we used the Locust load testing tool to evaluate the response time for standard actions against a Jira system in various states:

• Client data: a system with approximately two dozen Marketplace apps, 750,000 issues and 750 custom fields with global context.
• Empty: a fresh system with a single Project Management business project and no Marketplace apps.
• 3,000 Custom Fields: the above empty system with three thousand multi-line free text fields.
• 500,000 issues: the above empty system with this number of issues.

Load testing results**

As seen from above, adding a large number of custom fields with global contexts had an impact despite no other data in the system.

The effect of reducing the custom field contexts

Adding a project to the field context for a field requires a project re-index before the field is available for use.

In the above example, clicking the Change Context button for the Architect Approved custom field would delete the Yes/No options for this field, and these options will need to be recreated when a field configuration is recreated for this custom field.

Use Optimizer as a guide, don't blindly apply recommendations

The Custom Field Optimizer may recommend reducing the context of a field to zero projects. The effect is to delete the field configuration altogether. The impact of this is:

1. Not delete any issue data. The Optimizer bases its recommendations on whether there is any data for a particular custom field.
2. Deletes the field configuration. For example, reducing the context of a drop-down field to 0 projects deletes all options for that drop-down.
3. Hides the field from all project screens. We find that quite often, custom fields are created for a new process and project, then not removed when the process or project doesn't proceed. A non-production environment that accurately represents production is a sign of a well-managed system.

The Custom Field Optimizer is not a quick fix. The purpose for each field should be evaluated by identifying what screens it is on, then checking with the project leads about the status of that field. 

For example, after using the Custom Field Optimizer at a client site, the tool identified a drop-down field called "UAT Plan" and recommended it reduce its field context to 0 projects. It had a Global context, but no data at present. Further investigation identified that this field was used on a Governance Tasks project which, once upon a time, was under development but never launched. This project alone was responsible for the creation of 12 custom fields that have never been reused and were just contributing to slowing down the system. Overall, in the client's instance, up to 400 custom fields were identified to be redundant with similar background stories. 

Don't get into this situation

New project configurations should be first configured in a non-production environment. Following user evaluation and change approval, implement the configuration in production. This should highlight unused configuration elements such as redundant custom fields from being generated that then need change approval to remove.

If a field must be created in a production environment that isn't relevant to most projects, then a better way is to create the custom field with a Project context and the list of project configured.

_{** The client's system has always performed unusually slow with regards to creating issues. We believe this is due to poor issue indexing performance combined with a large number of apps.}

GLiNTECH are Platinum Solution Partners in Australia.

Contact our consultants to get expert advice.