3 ms·

The new design for Jira really sucks, has made everything slower, and crappier to use. Page load times of 10+ seconds are common. And no clear usability gains

The new design for Jira really sucks, has made everything slower, and crappier to use. Page load times of 10+ seconds are common. And no clear usability gains. I was a huge fan, but any more I just want to use GitHub.

Karunamon 8y ago
Please talk to your admins! In my experience, Most Jira slowdown issues can be traced back to permission checks. (And you can enable tracing in the system settings to verify this) If only your team needs to access it, set the instance to open permissions (I.e. most rights are set to “Everyone”) and then control access using the network or with a proxy in front. This took the instance I run at $dayjob from infuriatingly slow to no slower than any other web application. —Source: 5 years and counting Jira admin
- dasmoth 8y ago
  This is knowledge that could come in handy one day, so thanks. But fine-grained permissions are a fairly regularly cited reason for using Atlassian’s stuff over other (simpler...) offerings. This sounds a lot like “don’t try the fancy stuff because it’s unusably slow”.
  - Karunamon 8y ago
    I'd be willing to bet part of that is too many fine-grained permissions. It's a bit of a footgun. Basically, anytime you hit a ticket's page, Jira has to scan your account's group memberships and compare that against a litany of permissions to determine whether you can even see the ticket and what actions you can take with each of its fields. This is done to avoid showing you UI elements for things you can't do. If a given permission is set to "everyone", the check simply isn't done (kinda the equivalent of replacing a call to the user directory with a "return true;") I'm not talking entirely about reducing security here. I mean that if everyone in your team is a member of a certain security group, and only your team touches your Jira, set that permission to "everyone" rather than using that security group - the lookup is completely unnecessary in this case. Basically, you want as few permissions as possible to ensure the level of security you actually need. Often this isn't done, people go a bit crazy with permissions schemes trying to segregate this and that.

Karunamon 8y ago

Please talk to your admins! In my experience, Most Jira slowdown issues can be traced back to permission checks. (And you can enable tracing in the system settings to verify this) If only your team needs to access it, set the instance to open permissions (I.e. most rights are set to “Everyone”) and then control access using the network or with a proxy in front. This took the instance I run at $dayjob from infuriatingly slow to no slower than any other web application. —Source: 5 years and counting Jira admin

dasmoth 8y ago
This is knowledge that could come in handy one day, so thanks. But fine-grained permissions are a fairly regularly cited reason for using Atlassian’s stuff over other (simpler...) offerings. This sounds a lot like “don’t try the fancy stuff because it’s unusably slow”.
- Karunamon 8y ago
  I'd be willing to bet part of that is too many fine-grained permissions. It's a bit of a footgun. Basically, anytime you hit a ticket's page, Jira has to scan your account's group memberships and compare that against a litany of permissions to determine whether you can even see the ticket and what actions you can take with each of its fields. This is done to avoid showing you UI elements for things you can't do. If a given permission is set to "everyone", the check simply isn't done (kinda the equivalent of replacing a call to the user directory with a "return true;") I'm not talking entirely about reducing security here. I mean that if everyone in your team is a member of a certain security group, and only your team touches your Jira, set that permission to "everyone" rather than using that security group - the lookup is completely unnecessary in this case. Basically, you want as few permissions as possible to ensure the level of security you actually need. Often this isn't done, people go a bit crazy with permissions schemes trying to segregate this and that.