JIRA performance over long distance

23 juli 2018

Hi, my name is Bert van Dijk, and I’m an Atlassian specialist at TMC. A few weeks ago, I visited a customer that uses a number of different Atlassian applications, like Confluence, Crucible, Bitbucket and Jira.

These products are used at different locations and in general everything is working very well. This changed when they opened a new site in Asia. Loading JIRA issues within Asia was slow. Loading a kanban board took about a minute, while the employees in Eindhoven could load the same board in just seconds. In the end, they used a Remote Desktop Connection (RDS) to a computer located in the Netherlands to use Jira.

The Jira performance using RDS was comparable with the Jira performance experienced by employees in the Netherlands. Because using RDS is not a workable long time solution I started aroot-cause analysis. After this analysis it became clear that the root cause was a high latency.


As also described at this Atlassian page, Jira makes a lot of sequential web requests to load all the images and scripts referenced by a Jira web-page.

With a normal web page, content will be cached and reused as much as possible. Unfortunately, Tomcat (webserver behind Jira), instructs the browser to avoid all caching. This results in a situation where all images, texts, etc, will be sequentially loaded from the server. This increases the connection round trip time significantly and as a result the load time of a page.


Luckily, Atlassian comes with a workaround as well as a solution. The solution is a configuration change in Tomcat and the workaround is a configuration in the web proxy. In my opinion, the provided workaround is better than the solution. With the workaround, it is possible to have more control about the items to cache and about the expiration time. However, there are some consequences with caching. Also, the solution requires a restart of Jira, which takes minutes, while the workaround only requires a reload of the web proxy. The user won’t even notice this.

Using caching, comes with some innocent consequences, for example if somebody changes their avatar. A user loading the page will still see the old avatar for some time as it is in the browser cache.  Some less innocent consequences to consider is what if an attachment in Jira is updated (new version, same file name)?

What if Jira itself is upgraded and new versions of scripts are used? The old (cached) versions will still be used for the time being. A Jira upgrade is a planned change and action can be taken upfront, like to instruct people to clear their cache, or to let the cached content expire more quickly. By using the workaround provided by Atlassian, the cache can be disabled temporarily after an update to avoid outdated caches.


After taking everything in consideration, we can go to the results. The same Jira page (kanban board) is now loaded in less then 10 seconds instead of that minute. Still longer than the employees in Eindhoven, but significantly faster then with the original settings.

Do you also experience similar performance issues and you don’t know how to solve them? Contact details are on our website (https://www.tmcalm.nl/).