Removing a Field in Jira Can Improve Request Processing Speed by Up to 30 Percent

 During the tough times of the Covid-19 pandemic, I got a request from the Atlassian community to help with a Jira performance issue. Surprisingly, the solution was simple: removing an unused custom field in the default settings improved the performance for many projects. In this article, I’ll explain how this small change made a big difference.

The Problem

In 2020, as everyone adjusted to remote work and more online activities, users saw a big slowdown in many system, as on-prem Jira’s performance. The cause was hard to find, causing frustration.

Error Analysis

After adjusting logging level for all dedicated package (still unclear why package com. was only FATAL level), and

x

Upon delving into the logs, it became evident that there was an overwhelming number of errors linked to a particular custom field. This field, VIM: auto (customfield_16204), was part of the Jira Misc Custom Fields (JMCF) plugin. A typical log entry looked like this:

2020–07–30 13:45:19,458+0300 http-nio-8080-exec-11651 ERROR Bot 825x74537955x6 1jw7rw5 1.1.1.1,127.0.0.1 /rest/api/2/search [c.i.jmcf.fields.CalculatedWikiTextField] CalculatedWikiTextField: could not find formula for custom field ‘VIM: auto’ (customfield_16204) in context ‘Default Configuration for VIM: auto’. Navigate to the following URL to edit the formula: [https://jira.example.com/secure/admin/ConfigureCustomField!default.jspa?customFieldId=16204]

These errors accumulated due to a missing configuration for the custom field, which led to error messages every time a request was processed. The custom field was supposed to hold a formula, which was absent. This oversight had a cumulative effect, significantly impacting Jira’s performance.

Solution Implementation

To tackle this issue, I made a crucial but straightforward decision — removing the custom field from the default configuration. Despite its intended use and origin from the JMCF plugin, the absence of proper configuration rendered the field redundant and problematic.

Here’s what the log analysis showed before and after the field’s removal:

Before Removal:

$ cat atlassian-jira.log* | grep customfield_16204 | grep ERR | grep 2020–07 | wc -l

390326

After Removal:

$ cat atlassian-jira.log* | grep customfield_16204 | grep ERR | grep 2020–08 | wc -l

0

The errors dropped to zero after the removal, highlighting the significant impact of this seemingly minor field.

Conclusion

This experience underscored the importance of regular context checks and usage assessments for custom fields in Jira. Additionally, it emphasized the value of static analysis for error rates, a practice advocated by Google’s Site Reliability Engineering (SRE) principles.

By proactively managing and streamlining configurations, it is possible to achieve impressive performance improvements. This case demonstrates that sometimes, even a small change — like removing an unused field — can dramatically enhance system performance.