3 ms·

As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible. When you go to a page for

As a recovering Jira architect, you can drastically speed up the application by minimizing the use of permissions wherever possible. When you go to a page for a ticket, the app has to make multiple backend calls (which likely involve even more backend calls to a directory) to determine what groups you're in and so what you're allowed to do with that ticket and what UI elements to hide or show as a result. By turning off the permission checks, you replace all of this communication with the equivalent of 'return true'. Unless you're running a multi-department enterprise-wide Jira ($deity have mercy on your soul), you're better off eliminating permissions entirely and controlling access to the instance at the network. In other words, if only your developers need access to it, do not add your developer user group to the various site permissions, set the permission to everyone instead, and ensure only your developer's subnets can touch it in the first place.

jiggawatts 6y ago
It is a fundamentally poor design for permission checks to require additional network round-trips. A user's group memberships need only be evaluated once when they log on, with a refresh every few minutes at most. Access control lists can be easily cached, and then most access checks can be performed entirely in-memory. Instead of evaluating the full ACL every time, an additional trick is to take the cryptographic hash of the ACL and use that as a cache key. This both deduplicates the ACLs (which tend to be repetitive), and also allows (ACL,UserId) tuples to be efficiently cached. This way, a page with even a hundred controls becomes effectively a hundred hashtable lookups the second time it is viewed, and even the first time it is opened the overhead is no more than a millisecond. If turning off security makes a noticeable difference like you said, Atlassian has done none of these basic things. It indicates to me an incredible level of negligence.
- 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?
dbbk 6y ago
At the network? How would that work with people working remotely?
- gizmo686 6y ago
  VPNs
- Karunamon 6y ago
  You can still grant login permissions, but anything beyond that is just asking for it.
deleted 6y ago
[deleted]

jiggawatts 6y ago

It is a fundamentally poor design for permission checks to require additional network round-trips. A user's group memberships need only be evaluated once when they log on, with a refresh every few minutes at most. Access control lists can be easily cached, and then most access checks can be performed entirely in-memory. Instead of evaluating the full ACL every time, an additional trick is to take the cryptographic hash of the ACL and use that as a cache key. This both deduplicates the ACLs (which tend to be repetitive), and also allows (ACL,UserId) tuples to be efficiently cached. This way, a page with even a hundred controls becomes effectively a hundred hashtable lookups the second time it is viewed, and even the first time it is opened the overhead is no more than a millisecond. If turning off security makes a noticeable difference like you said, Atlassian has done none of these basic things. It indicates to me an incredible level of negligence.

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?

dbbk 6y ago

At the network? How would that work with people working remotely?

gizmo686 6y ago
VPNs
Karunamon 6y ago
You can still grant login permissions, but anything beyond that is just asking for it.

deleted 6y ago

[deleted]