Speed up your response times across the globe using a content delivery network.
You’d be hard-pressed to find a modern-day enterprise that doesn’t employ distributed teams across the globe. For many customers, it’s not a question of where you have distributed users, but more so where you don’t. And as you scale Atlassian tools, more and more of these teams are working from your primary instance, and their physical distance from the instance server can have a negative impact on performance. One customer even admitted that simple Jira actions take four times as long for employees in their Tokyo office.
You can’t have half your users pinging you at all hours of the night because Jira isn’t as fast as they want it to be, just as it’s unfair for those same users to wait eight seconds for a Jira issue to load. This is the reason we first introduced support for distributed teams in Bitbucket with smart mirroring.
Now, we’ve added support for CDN (content delivery network) to our Data Center products. With a CDN, you’ll not only accelerate the experience of your geographically distributed users, but reduce the peak load on your primary application instances, boosting performance all around. CDN support is available for our Data Center editions of Jira Software 8.3, Jira Service Desk 4.3, and Confluence 7.0, and Bitbucket 6.8. Let’s take a look under the hood to see how it all works.
Tip
If you’re interested in learning more about Data Center, or think the time is right to make the move, start the conversation here.
What do CDNs do?
CDN stands for content delivery network, a globally distributed network of edge servers that cache static resources locally, such as CSS, JavaScript, or fonts. When distributed teams work from a location that’s geographically distant from their server location, it typically means they have to wait longer for a page to be fetched, an issue to open, or a board to load. The purpose of a CDN is to speed up that response time as much as possible by distributing the static assets of these actions spatially, relative to end-users.
Let’s take Jira, for example. If you look at the client-to-server requests made to load and view a Jira issue, you’ll see that roughly 80% of those requests come from static resources that can be cached and delivered by a CDN. That means the bulk of the actions that cause slow response times are delivered by a nearby edge server, improving response time and reducing the load of the primary instance.
How a CDN affects performance
We’ve seen customers with as many as 100 and as few as three remote locations working from the same instance, and in both scenarios, they saw some form of performance degradation. When you enable a CDN, the first request for each static asset returns to the Jira instance and the CDN picks up the remaining static asset requests, delivering them from a nearby cache, rendering your instance faster for remote users and reducing your Jira request load.
Tip
We highly recommended that your load balancer, firewall, or proxy allow HTTP/2 traffic. Using HTTP/2 will allow for the best performance while using a CDN.
After initial testing for Jira, we’ve already seen encouraging results, with up to 50% improvements in response time for distributed teams. That means those users in Tokyo are loading issues twice as fast, and that makes a big difference.
We tested the performance of Jira’s “view issue” action with and without a CDN on a 350ms link, from Europe to New York over an AWS infrastructure. The results – as shown above – were eye-opening. Without a CDN, we saw average response times of 9,285ms. With the CDN enabled, we saw the average drop to 4,439ms. The time it took a remote user to load and view a Jira issue was cut in half. (Learn more about how to configure your CDN for Jira here.)
We’ve also already seen impressive results from customers who have implemented a CDN. One customer shared that they even saw their index size shrink from 24GB to 3.5. Now obviously, results will vary based on factors like network latency, request load, and browser cache, but taking advantage of the benefits a CDN provides can improve performance for all of your teams, resulting in a better and more equal user experience across the entire business.
Getting started with CDN
For those of you who use AWS, we’ve provided CloudFormationTemplates for AWS CloudFront, available as a single-line configuration in our updated templates so you can get up and running in no time. You can find all of our AWS deployment resources in this repository. Regardless, you can use any CDN, public or private, including reverse-proxy caches for those that run completely behind the firewall and cannot leverage from the public CDN providers.
Tip
For all these use cases, you will find dedicated documentation describing how to configure your application firewall to allow CDN traffic into your cluster, supported with an example configuration for AWS Application Firewall, or how to set up a reverse proxy caching within your bare metal infrastructure.
Optimizing performance at scale has always been a core tenet of our Data Center products, and CDN support goes a long way in helping achieve that. But that’s not all we’re doing to improve performance, we’ve introduced the latest evolution of smart mirroring with smart mirror farms in Bitbucket that scale and increase CI/CD capacity. This new feature allows users to cluster mirrors into “farms” grouped behind a load balancer to reduce time spent waiting for those build results.
CDN support is currently available with the Data Center editions of Jira Software 8.3 and Jira Service Desk 4.3, and coming soon to Confluence and Bitbucket. If you’d like to learn more about how we’re building better performance for distributed teams in both CDN support and smart mirror farms, check out the webinar below.