Overview
The ability to set custom fields makes Jira a powerful workflow management tool, allowing you to create highly specificobjectsfor modeling the way yourorganizationswork. However, like all good things, too much canbe detrimental to Jira's performance and administration. Here, we explain how using custom fields affects Jira's performance; we also provide several recommendations on its proper use and optimization.
Too many custom fields can slow down your instance
The response time of any action that requests or processes custom issue details (viewing, searching, creating/editing issues, and adding comments) is affected by the raw number of custom fields in Jira. Our scaling tests for Jira 7.7 revealed as much:
Figure 1: Average response times per action (in milliseconds): custom fields test |
When wetested1different user actions on Jira instances with 1400 and 2800 custom fields, the latter showed significant differences in response times forAdd Comment,Create Issue, andEdit Issue.Considering that users spend most of their time on Jira performing these three actions, it's clear that you need to pay close attention to the number of custom fieldsinyour Jira instance.
We also tested the same set of user actions across eight other Jira instances, doubling a different data point each time.The following table shows aggregates of all average response times, for all actions in each test:
Figure 2: Aggregates of average response times (in milliseconds) for all actions: custom fields test |
This graph suggests that of the eight data points we tested, the number of custom fields had the greatest effect on average response times.
Identify and clean up unused custom fields
Here's three strategies for reducing custom field bloat in your instance:
- Deleteany unused custom fields.
- Mergecustom fields that see very little use.
- Limit the scopeof the custom fieldsto specific projects context.
Before removing or consolidating any custom fields, discuss them with Business Owners and ensure that your changesare tested in a QA environmentbefore rolling them out to production. This is a time-consuming process, but youneed to be careful sothat no critical data is lost.
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
- Reducing the work done by other nodes in the cluster during replication
Custom fields usage
In Jira Data Center 8.16 and later, the Custom fields page includes new columns that show the usage of your custom fields—how many issues are actually using them and when was the last value made. You can sort by these columns and use additional filters for value updates to quickly find good candidates for deletion. For more info, see Analyzing the usage of custom fields.
Jira's built-in custom fields optimizer
You can start the process of cleaning up your custom fields through Jira's built-in custom fields optimizer. This feature lets you scan your instance's custom fields and highlight the ones you can optimize. SeeOptimizing custom fields for more information.
SQL Database queries
If you need to take a more detailed look at your Jira instance's custom fields, use the following SQL queries.
This SQL query can also return custom fields implemented by plugins; as such, those custom fields may be using their own datastore. Have these custom fields reviewed by Business Owners before taking any action.
select count(*), customfield.id, customfield.cfname, customfield.descriptionfrom customfield left join customfieldvalue on customfield.id = customfieldvalue.customfieldwhere customfieldvalue.stringvalue is null and customfieldvalue.numbervalue is null and customfieldvalue.textvalue is nulland customfieldvalue.datevalue is nullgroup by customfield.id, customfield.cfname, customfield.description;
This query returns all custom fields that have been use less than five times.
select customfield.id, count (*)from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfieldgroup by customfield.id having count (*) < 5order by count (*) desc
This query also excludes Agile, Service Desk, Capture, and Portfolio fields.
select field.id, field.cfname from customfield field where field.cfname not in (select item.field from changeitem itemJOIN changegroup cgroup ON item.groupid=cgroup.idwhere item.fieldtype='custom' and cgroup.created > 'YYYY-MM-DD') and customfieldtypekey not like '%com.pyxis.greenhopper%'and customfieldtypekey not like '%com.atlassian.servicedesk%'and customfieldtypekey not like '%com.atlassian.bonfire%'and customfieldtypekey not like '%com.atlassian.jpo%'
This query uses the complete custom field ID (for example, customfield_10301).
select id, entitytype, entityid, username, to_timestamp(lastviewed/1000) as lastviewed, data from userhistoryitem where entityid='customfield_10001'order by lastviewed desc;
select * from customfield where customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:select';
select * from searchrequest where reqcontent like '%Field Name%' or reqcontent like '%10001%';
This query uses the complete custom field ID (for example, customfield_10301).
select * from jiraworkflows wf where wf.descriptor like '%customfield_10301%';
SELECTcf.id id, to_char(min(ji.created), 'YYYY/MM/DD'),to_char(max(ji.updated), 'YYYY/MM/DD'),count(distinct(ji.id))FROM CUSTOMFIELDVALUE cfvleft join JIRAISSUE jion cfv.ISSUE = ji.id left join CUSTOMFIELD cfon cf.id = cfv.customfield GROUP BY cf.idORDER BY cf.id
SELECTcf.id id, to_char(min(ji.created), 'YYYY/MM/DD'),to_char(max(ji.updated), 'YYYY/MM/DD'),count(distinct(ji.id))FROM CUSTOMFIELDVALUE cfvleft join JIRAISSUE jion cfv.ISSUE = ji.id left join CUSTOMFIELD cfon cf.id = cfv.customfield GROUP BY cf.idORDER BY cf.id
Atlassian Marketplace plugins to identify/remove custom fields
Jira Command Line Interface (CLI): Includes a prebuilt 'removeCustomField' function
Configuration Manager for JIRA:Great for identifying and resolving custom field conflicts. SeeDuplicate Custom Fields (Botron Software site)for more details.
Admin Tools for JIRA: Features the ability to identify which custom fields are currently in use and clone custom fields.
- Cleaner for JIRA: Lets you to list Custom Fields, how they are used, and delete them if necessary.
- Custom Fields Usage for JIRA:Lets you view Custom Fields with their name, type and description. It will also mark Custom Fields that were never set in any issue, and you can delete them in one click.
Set up governance around custom fields
Onceunused or rarely usedcustom fields have been identified and removed successfully from an instance (or merged), set uprules and guidelinesfor creating new custom fields in the instance. This will help establish a disciplined approach, helpingprevent it from affecting your instance's performance. Establishing governance around Jira customization is useful in balancing the growth of the instance with its ability to serve the needs of its users.
Afew things to keep in mind here:
Evaluate requests for new custom fields:When users request new custom fields, establish a process for vetting the necessity of the request. Meet with the users to interpret their requirements for the fields and figure out if an existing field can be repurposed or if a field is needed at all.
Verify the purpose of new custom fields:Ensure that the information captured by each field serves a justifiable purpose. If the data is not used to work on the issue, or for reporting, then it is not needed. Track the number of custom fields actually being used on a quarterly basis or as frequently as it is practical in your organization.
Establish and share a governance policy:Create a clear and definitive set of regulations that establish how new objects such as custom fields, workflows, and other customizations are added to Jira.
Get executive backingShare your governance policy with relevant managers and executives at your organization and emphasize the need for their support in keeping Jira running smoothly. Be ready with facts to substantiate your policies and show how the lack of governance affects the performance of the instance and ultimately impact the end-users. You can even show the test results from this article.
Other recommendations
Some other useful Do's and Don'ts for managing custom fields are summarized below:
DO
- Reuse existing fields when possible.
- Make field names as generic as possible.
- Give your custom fields useful descriptions, including examples of validvalues.
- Format custom fields consistently (for example, capitalization). Whenever possible, keep them consistent with Jira defaults.
- Be careful of trailing spaces and other non-visible characters added to custom field names. These will make using scripts harder.
- Err on the side of flexibility. For example, a multi-select field is more flexible than a single-select field.
- Translate custom field names for your users who are using a different language pack.
- Know how and when to use custom fieldcontexts.
- Use theWhere is my field?feature to track down missing fields.
- Have agovernance policyand make it easy for users and executives to find.
- Use custom fields contexts appropriately. For example, avoid using global context when a custom field is only being in used in one project.
- Avoid settingdefault valuesfor your custom fields whenever possible.
- When creating custom fields with a drop-down list, try to minimize the number of options available.
DON’T
- Don’t create custom fields with duplicate names. This can lead to administration mistakes, reporting issues, and custom script errors.
- Don’t create option fields that have to be updated frequently. For example, a select list with usernames will quickly become outdated as people’s roles change.
- Don’t add the option valueNone.This option already exists when the field is made optional and adding it to the list makes reporting harder.
References
You can also refer to Practical JIRA Administration: Using JIRA Effectively: Beyond the Documentation by Matt Doar for more advice on effectively managing custom fields.
The data points used in this article were collected as part of a series of scaling tests between different versions of Jira. For more details about the hardware, results, and methodology of those tests, seeScaling Jira 7.7.
We're here to help
This article features advice typically provided byAtlassianTechnical Account Managersto customers when custom field use starts affecting performance.Technical Account Managerscanprovide strategic guidance to help you choose the right methods to manage your custom fields or even mitigate other performance problems.
OurPremier Support teamperforms health checks by meticulously analyzing your application and logs, to ensure that your application's deployment fully meets the needs of your users. If the health check process reveals any performance gaps, Premier Support can recommend possible changes to yourinstance.
Was this helpful?