3 ms·

About 6 years ago I maintained the LDAP integration code for Atlassian Crowd, which is/was reused by Jira (& Confluence). Jira (both Cloud and Server) does cac

by caspar 6y ago

About 6 years ago I maintained the LDAP integration code for Atlassian Crowd, which is/was reused by Jira (& Confluence). Jira (both Cloud and Server) does cache permissions, heavily. Jira effectively has a local cache of user and group relationships for all users who have access to a given blah.atlassian.net Jira, and caches lookup results in a shared cache too. It's complicated by having well over a hundred thousand active Jira sites spread over several hundred stateless servers, which does make effective caching a bit trickier. AFAICT Jira Cloud's slow feel currently stems largely from the front-end, amplified by the debacle that is modern front-end engineering. It's tricky to get 300+ engineers to ship fixes and enhancements in a multi-million line codebase over 15 years old on a good day. Feature creep in design systems, constant ecosystem churn, and poor build tools all conspire to make it that much harder to prevent performance regressing. But even knowing all that - yeah, I wish that Jira's performance was 5x better too :) Disclaimer: am still employed by Atlassian but all views are my own, things may have changed a bit since I haven't touched any Jira code in ages, etc.

jiggawatts 6y ago
The permission performance issue I was commenting on (apparently) resides in the back-end code of the on-premises Jira server. The front-end code issues other people have raised seem like the type that could be solved by simply turning on Gzip or Brotli compression for static JavaScript content in the web server. All of this seems to be incredibly basic tuning to have been overlooked, especially given that every public discussion of Jira mentions its slow performance! As for the Jira Cloud: I just did some quick experimentation. I spun up a free-tier account and created an empty issue. This is the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, high-performance client link, same region as the Atlassian PaaS server, etc... At least here, most of the traffic is coming from a CDN that enables compression, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of. Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form! This required 1.2MB of uncacheable content to be transferred. With the cache off, a total of 27.5 MB across 151 files taking 33 seconds is required! The total text displayed on the screen is less than 1 KB. The page took 4.35 seconds of CPU time on a gaming desktop PC with a 3.80 GHz CPU and a gigabit fibre Internet connection. A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds! Is no one responsible for performance at Atlassian?

by caspar 6y ago

jiggawatts 6y ago

The permission performance issue I was commenting on (apparently) resides in the back-end code of the on-premises Jira server. The front-end code issues other people have raised seem like the type that could be solved by simply turning on Gzip or Brotli compression for static JavaScript content in the web server. All of this seems to be incredibly basic tuning to have been overlooked, especially given that every public discussion of Jira mentions its slow performance! As for the Jira Cloud: I just did some quick experimentation. I spun up a free-tier account and created an empty issue. This is the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, high-performance client link, same region as the Atlassian PaaS server, etc... At least here, most of the traffic is coming from a CDN that enables compression, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of. Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form! This required 1.2MB of uncacheable content to be transferred. With the cache off, a total of 27.5 MB across 151 files taking 33 seconds is required! The total text displayed on the screen is less than 1 KB. The page took 4.35 seconds of CPU time on a gaming desktop PC with a 3.80 GHz CPU and a gigabit fibre Internet connection. A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds! Is no one responsible for performance at Atlassian?