We have a rule in place that nothing we ship can regress performance. Period. At the same time, we're opening up more data centers in more countries to help with geo-based performance. Some of the major items to be undertaken this year include moving Jira to have more Single Page App (SPA) transitions to avoid page loads altogether.
Earlier this year, we announced a migration to AWS which allows us to leverage features such as Auto Scaling our infrastructure and other cloud-scale services. These capabilities have allowed us to improve our availability and reliability.
We are also investing heavily in our frontend technologies to improve the performance of our page load times. For example, the new next-gen Jira boards and view issue pages are all using Server Side Rendering technology to return raw, old-school HTML direct to the browser for rendering. This allows the page to be shown to the user immediately, without the need for multiple round trips back to our servers or CDNs for javascript, css and data. We saw massive improvements in page load times by introducing this for these new key experiences and plan to continue making further similar investments for all other parts of Jira.
Our metrics show we had some of our lowest performance around September last year. Since then, with dedicated investment, we managed to move the needle on performance and are continuing to move it. If you aren't feeling it, let's get in touch with support to see what is going on in your instance.
> We have a rule in place that nothing we ship can regress performance.
Then how did you guys end up with such a pile of shit?
Pardon my language, but I'm forced to use Jira at work and it makes me feel bad for everybody in the same situation.
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.
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.
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.
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.
BTW- Try spinning up a next-gen project in Cloud and see if it is easier, turn on scrum or kanban or estimations with a single click. Filter a board without learning JQL. You get the idea. Report back. LMK.
Having deployed a dozen or so JIRA instances: it usually comes down to tuning and hardware selection. JIRA can be fast, but admins usually don't pay enough attention to better configuration.
Well, after playing with it this morning using a dummy project, it is definitely faster than the (horribly, horribly slow) JIRA Cloud I can't avoid using at work.
But it is still sloooow.
Notice when I switch from "Board" to "Roadmap" it takes 4-5 seconds to load... every time:
I hope the new Jira provides less flexibility, because too many people straight up don't know how to use boards well. It's incredible. There's so many ways in the old system to do shit and people readily abuse it at every turn.
I've been enjoying the new Jira boards for their simplicity. Keep it up Atlassian.
20 comments
[ 3.8 ms ] story [ 52.9 ms ] threadUsing JIRA is a pain, and I really hope they address it in the redesign.
While there are a lot of issues with the current design, I don't mind if it stays same, as long as it just gets at least a few times faster.
We've been looking for other solutions because of poor Jira performance.
Earlier this year, we announced a migration to AWS which allows us to leverage features such as Auto Scaling our infrastructure and other cloud-scale services. These capabilities have allowed us to improve our availability and reliability.
We are also investing heavily in our frontend technologies to improve the performance of our page load times. For example, the new next-gen Jira boards and view issue pages are all using Server Side Rendering technology to return raw, old-school HTML direct to the browser for rendering. This allows the page to be shown to the user immediately, without the need for multiple round trips back to our servers or CDNs for javascript, css and data. We saw massive improvements in page load times by introducing this for these new key experiences and plan to continue making further similar investments for all other parts of Jira.
Our metrics show we had some of our lowest performance around September last year. Since then, with dedicated investment, we managed to move the needle on performance and are continuing to move it. If you aren't feeling it, let's get in touch with support to see what is going on in your instance.
Then how did you guys end up with such a pile of shit? Pardon my language, but I'm forced to use Jira at work and it makes me feel bad for everybody in the same situation.
* 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.
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.
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.
BTW, is there any chance of a dark theme on either the web or mobile apps?
But it is still sloooow.
Notice when I switch from "Board" to "Roadmap" it takes 4-5 seconds to load... every time:
https://www.dropbox.com/s/zlz74h1azxg3gp4/2018-10-19-new-JIR...
This looks better to me than the current JIRA, but also looks like slow performance of basic operations is still Problem #1.
I've been enjoying the new Jira boards for their simplicity. Keep it up Atlassian.