Do I need to add a caching layer between Jira and the database?
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Question
With cache solutions (such as Memcache and Redis) being readily available for deployment on cloud services such as AWS, would adding such a caching layer between my Jira and the database speed up my Jira?
Answer
Jira is already out-of-the-box caching frequently used information in the application to minimise the need for it to reach out to the database. It only does so when either something gets changed or a certain internal cache has expired and those expiration times have been carefully tuned during the development phase to fit each cache's purpose. Jira also handles the replication of this cache between the nodes to ensure that they all have the same information in their cache.
Introducing an extra cache layer between application and database is not a supported configuration. There are multiple reasons for this.
Certain functionality like permission schemas and authorisation of user actions rely on that Jira is in control of what is cached and not. Jira keeps the user permissions in cache for the sake of speed, but as soon as anything changes for a user's permissions that cache is immediately updated and the change pushed to the other nodes. While this takes places, that particular cache is locked and can not be used for authorisation as that could otherwise be a security risk.
If Jira is not in control of all the caches it uses, there is a serious risk of creating data inconsistencies or even a corrupted database if Jira "thinks" it is reading a non-cached value directly from database while it in fact may not be. That would put Jira in an unknown and uncontrolled state, which is not supported.
It adds an extra layer of complexity of something that is also not an Atlassian product and it can not be guaranteed that Atlassian Support can help you.
This custom caching layer is not being taken into account when developing and testing Jira. Even it can work fine at one point in time, no functionality can be guaranteed in future upgrades with this configuration in place.
For caching of static resources for faster delivery of pages, that can be taken care of in caching at the front end rather than at the database level. For example, if you have a distributed work force you can benefit from using a Content Delivery Network (CDN) if you are not doing so already.
Was this helpful?