3 ms·

In my mind it's clear, when I see those animations, that it will be slower. Maybe it will even have a splash screen with a progress bar.

by hawski 8y ago

seanjregan 8y ago
Give it a try. https://www.atlassian.com/software/jira/try https://www.atlassian.com/software/jira/try Miss those robots on the spin up screen that you might remember from that past? It's getting a lot faster. We're going to keep going.
- Nullabillity 8y ago
  Yeah, don't bother. We just started using it at work a few days ago. Not a single page loads in less than 7 seconds (with a primed cache, a completely fresh load takes 30+). Every page also pulls in 50+ subrequests, many of which have caching disabled. It's a new org, new project, and a single digit number of issues, so this can't be a scale issue (though I dread to imagine how awful that would be). That would be understandable (though hardly acceptable) for an SPA, but this is Enterprise, where every navigation still requires a full reload, and the page you're actually looking for (the issue page) is never less than 3 links away from the useless dashboard that some designer put in because that's what all the cool kids do. How did this shit get past QA? Did the QA people give up on trying to file any issues because the UI was so slow? Do all developers at Atlassian have a Stockholm Syndrome that would put Microsoft to shame? That this actually made it through development (nevermind that it somehow has paying users) is absolutely mind-boggling.
  - seanjregan 8y ago
    We are running a 3000+ seat instance at Atlassian on the same cloud as everyone else with nothing close to that performance. Let's get you on the line with support to see what's off.
  - indemnity 8y ago
    At least they have a rule not to regress performance! Best to institute such a rule when it’s already slow as molasses, like they did, that way you can hit your KPIs while still shipping garbage.
java-man 8y ago
I suspect most of the slowness of Jira is due to the back end, not the front end.
- seanjregan 8y ago
  The back-end has been getting totally rebuilt as part of this. The move to AWS has opened up a lot of options also. For example, we can take advantage of: * elastic scaling, * large in-memory caches like memcached, * data locality, * alternative data stores better suited to our data structures such as dynamoDB, * different instance sizes, * dedicated asynch batch processing nodes, * specific instance sizes suited to specific workloads, etc etc We are also optimizing how and where we store data. We are already storing data in different AWS regions (closer to our customers), however, we are going to also start getting smarter about ensuring the data is actually in the optimal region for the majority of users on a site. There is also room for improvement in tuning how we query data for issues with many fields, or instances with very with complex permissions enabled. This will require optimizing the SQL we use to retrieve data, to provide all we need to render a Jira issue as fast as possible and exploring other storage technologies for fast data retrieval.

In my mind it's clear, when I see those animations, that it will be slower. Maybe it will even have a splash screen with a progress bar.

by hawski 8y ago

In my mind it's clear, when I see those animations, that it will be slower. Maybe it will even have a splash screen with a progress bar.

seanjregan 8y ago

Give it a try. https://www.atlassian.com/software/jira/try https://www.atlassian.com/software/jira/try Miss those robots on the spin up screen that you might remember from that past? It's getting a lot faster. We're going to keep going.

Nullabillity 8y ago
Yeah, don't bother. We just started using it at work a few days ago. Not a single page loads in less than 7 seconds (with a primed cache, a completely fresh load takes 30+). Every page also pulls in 50+ subrequests, many of which have caching disabled. It's a new org, new project, and a single digit number of issues, so this can't be a scale issue (though I dread to imagine how awful that would be). That would be understandable (though hardly acceptable) for an SPA, but this is Enterprise, where every navigation still requires a full reload, and the page you're actually looking for (the issue page) is never less than 3 links away from the useless dashboard that some designer put in because that's what all the cool kids do. How did this shit get past QA? Did the QA people give up on trying to file any issues because the UI was so slow? Do all developers at Atlassian have a Stockholm Syndrome that would put Microsoft to shame? That this actually made it through development (nevermind that it somehow has paying users) is absolutely mind-boggling.
- seanjregan 8y ago
  We are running a 3000+ seat instance at Atlassian on the same cloud as everyone else with nothing close to that performance. Let's get you on the line with support to see what's off.
- indemnity 8y ago
  At least they have a rule not to regress performance! Best to institute such a rule when it’s already slow as molasses, like they did, that way you can hit your KPIs while still shipping garbage.

java-man 8y ago

I suspect most of the slowness of Jira is due to the back end, not the front end.

seanjregan 8y ago
The back-end has been getting totally rebuilt as part of this. The move to AWS has opened up a lot of options also. For example, we can take advantage of: * elastic scaling, * large in-memory caches like memcached, * data locality, * alternative data stores better suited to our data structures such as dynamoDB, * different instance sizes, * dedicated asynch batch processing nodes, * specific instance sizes suited to specific workloads, etc etc We are also optimizing how and where we store data. We are already storing data in different AWS regions (closer to our customers), however, we are going to also start getting smarter about ensuring the data is actually in the optimal region for the majority of users on a site. There is also room for improvement in tuning how we query data for issues with many fields, or instances with very with complex permissions enabled. This will require optimizing the SQL we use to retrieve data, to provide all we need to render a Jira issue as fast as possible and exploring other storage technologies for fast data retrieval.