6 ms·

There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow. Atlassian seems to make a lot of money, so I guess they're

by Lazare 6y ago

There's a hundred small issues with Jira, but there's one huge one: It's slow. Really, really slow. Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone, but from my point of view I have a simple process for evaluating tools: 1) Can I use it at all? 2) How many of the features I want does it have? I'm pretty sure Jira would score great on the second question, but since it hard fails the first, I'll never know. And it's been slow for so many years now, I assume they have no interest or ability to fix it. And their slow drift towards cloud installs over letting people self host isn't helping them either since, embarrassingly, their cloud instances seem to be even slower. (Incidentally, there's a lot of competition in that space, but I've been pretty happy with Clubhouse. I wouldn't mind a few more features, but it's good enough. More importantly, the UI is clean and snappy, and that hides a multitude of sins.)

eplanit 6y ago
It's the mainframe app of our time.
- bdavis__ 6y ago
  nah. mainframe apps are very snappy with that text only interface.
  - nikau 6y ago
    Damn right, I still miss Infoman for change management, you could just type ahead with command line interface to do everything if it was under load. Now everyone uses service now with 50 unnecessary subtickets and multi second delays moving around the web interface.
core-questions 6y ago
Yes, it's slow as balls. I run my own Jira for ~100 users and, despite throwing as much hardware at it and its PostgreSQL database as possible, it's still extremely slow clicking around and trying to use it. Database operations that would have been fast against simple MySQL 15 years ago on a single core server take seconds. What is it doing that makes it so slow?? The PostgreSQL server has most of the working set of data cached into 64GB of memory, for pete's sake, and still it's not enough to make it fly. Cloud Jira is unusably slow in comparison, too, and when the Atlassian server licenses are not available any more (soon!) and we're forced with having to migrate, I'm not sure what to do. Bite the bullet and just accept the abysmal performance for an easy migration, pay through the nose for the Data Center license, or get people running on a new tool?
probably_wrong 6y ago
> Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think. You don't like that the ticket form has 50 fields you don't need? No problem! All you need to do is to convince your manager to contact support and tell them to track less data about your progress. I bet your manager will love that. And once they got the foot on the door, who is going to convince the company to migrate away from them?
- xxpor 6y ago
  >My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think. That's all enterprise software in a nutshell. And a huge reason why things like Slack and Trello became so popular. They targeted users first without having to get the enterprise to buy it up front.
  - toper-centage 6y ago
    I think trello is fine. Its so simple and fast and not trying to overachieve. Or did Atlassian already screw it up?
    - npunt 6y ago
      Not really, but they did recently migrate the login to Atlassian so what was once a quick one-step process becomes a multi-page, multi-redirect mess.
- ccwilson10 6y ago
  I honestly wish it was that simple for us but convincing management is a fairly sales-driven approach and our marketing model is heavily self-serve. We do have a product called Jira Align that's targeted closer to what you're describing. I'd attribute more of the spread to the concept of "Jira is the defacto" fwiw. Chuckled at convincing managers to track less data. Internally we subscribe to a "less is more" approach and try to limit required fields as much as possible. I bet we feel more willing to contact Jira admins to make changes, though, since we own the product itself. Concur that migrating away from Jira is tough and probably helps keep people in the ecosystem. I haven't met anyone at Atlassian, though, who ever wanted that to be the reason why people stay. I think Jira can be awesome when it's set up well but some stakeholders can get a bit, uh, heavy-handed when deciding on "the process".
kwertyoowiyop 6y ago
It has that slowness that makes my soul die a little every time I bring up a page, every time I click on a link, every time I make an edit, every time I... What’s the opposite of “delightful”?
- _Understated_ 6y ago
  > What’s the opposite of “delightful”? Unpleasant?
- Tempest1981 6y ago
  Painful?
- 3np 6y ago
  Delightless
- muststopmyths 6y ago
  >What’s the opposite of “delightful”? deleterious fits in an alliterative way
- SoylentYellow 6y ago
  excruciating
- maest 6y ago
  Lightful?
imbnwa 6y ago
Its a poorly optimized Angular app IIRC
- anonymousCar 6y ago
  I have no metrics in the frontend, it's reasonably fast for me. It's the interactions with the backend that are slow. This is evident for anyone that's used the api.
  - nicoburns 6y ago
    Typing in the description field of a ticket lags and spins up the fans on my laptop. It's doing something wrong.
    - mgkimsal 6y ago
      Unrelated, but... we've got a jira input field that keeps moving the cursor to the end of the input field on each keypress. Perhaps that all do that(?), but it's noticeable when I'm pasting in a URL and want to change the beginning part of the URL. Example: server-abc.example.com, need to change to server-def.example.com - changing the A then moves the cursor to after the .com, which is also beyond the end of the input box, and thus invisible.
waiseristy 6y ago
A customer I am currently working with has a JIRA instance which literally, looking at the firefox network inspector right now, takes 13.04 seconds before it's done loading. It takes at least 10 seconds before the page will even let me scroll. I can't even comprehend how they have managed to get this poor of performance.
- Liskni_si 6y ago
  Does it keep reloading batch.js? Is it because the URL is changing or is it just not getting cached at the browser? Answering these questions is a first step to speed up Jira. See also my comment from 2018: https://news.ycombinator.com/item?id=18511497 https://news.ycombinator.com/item?id=18511497
  - jiggawatts 6y ago
    This is like web optimisation 101. What you did is a clever workaround, but it shouldn't be necessary! Why isn't the Jira server sending compressed content in the first place? If those javascript files are static, they could even cache the compressed versions for extra speed!
Karunamon 6y ago
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.
systematical 6y ago
This is my biggest gripe. It's slow and clunky. Confluence is also terrible (slow and clunky). Mkdocs, which is markdown powered, is much better for documentation. My remaining issues with jira are not with jira at all. Jira can fix its slow ass software, it's feature backlog and I can use mkdocs over confluence. Jira can't fix poor project requirements and management. How fucking dumb are you if you can't even write a bug report? It's what happened, what I expected, and a how to reproduce bullet list.
pigeonbacon 6y ago
Do you know that this post is actually breaking the JIRA ToS? Seriously, it's in their ToS that you can't complain about how slow JIRA is... > Except as otherwise expressly permitted in these Terms, you will not...(i) publicly disseminate information regarding the performance of the Cloud Products https://www.atlassian.com/legal/cloud-terms-of-service https://www.atlassian.com/legal/cloud-terms-of-service JIRA sucks
- Kwpolska 6y ago
  The OP never stated they’re using it on Atlassian’s cloud, and Jira is available for on-premises deployments too, where those terms don’t apply.
- bombcar 6y ago
  This is phenomenally hilariously bad, but quite common (I believe Oracle has a "no benchmarks" clause).
dan-robertson 6y ago
See also, a comment from someone who worked on JIRA: https://news.ycombinator.com/item?id=25212441 https://news.ycombinator.com/item?id=25212441
antaviana 6y ago
> Atlassian seems to make a lot of money Atlassian has been losing money in every quarter for quite a few quarters. But its market capitalization has been generally increasing so shareholders who sold their stock probably made money.
frombody 6y ago
Jira is typically not slow. It's usually the plugins you have installed. Some plugins like big picture even have their own databases that need to be updated separately from the plugin, and can cause performance issues. Start jira in safe mode and check the performance. Then check your plugins one at a time until you find the culprit. They also have some nice built in tools that often help you find the source of these problems. It's a product, but it's also a platform, and sometimes the stuff that is built on the platform causes the platform to buckle.
GoldenStake 6y ago
Slow, unresponsiveness, and worst of all lagged resizing caused my biggest daily annoyances in Jira. Several times a week, I click a task, and just want to click the link to an associated epic, or something. But that link keeps dipping and dodging my mouse. I joined another team which used Asana, and it's much better, although certain things can still be slow.
nikau 6y ago
> there's one huge one: It's slow. Really, really slow This is spot on. Its the same reason I hate Sharepoint - every implementation I've used was always incredibly slow, so I would only ever use it when my arm was forced. I miss old school "legacy" style apps that cached stuff so moving around the app is quick. Even simple apps like slack suck these days as it always takes a few seconds to move around windows, why the hell can't it cache things? IRC clients in the 90s did about the same amount of stuff and they never lagged swapping servers or channels.
- redisman 6y ago
  I would guess because in slack the history can change when irc is basically a read only log. Slack has threads, edits, deletes and emojis etc. that will change the history so you can’t cache it
  - nikau 6y ago
    I would prefer slack to update the channels in the background rather than on demand when I click a channel to view. This would probably be a bit more resource intensive, but I have network and CPU bandwidth to spare.
leokennis 6y ago
A year ago, for backlog management we migrated from JIRA to ServiceNow. You don’t know how good you have it with JIRA.

by Lazare 6y ago

eplanit 6y ago

It's the mainframe app of our time.

bdavis__ 6y ago
nah. mainframe apps are very snappy with that text only interface.
- nikau 6y ago
  Damn right, I still miss Infoman for change management, you could just type ahead with command line interface to do everything if it was under load. Now everyone uses service now with 50 unnecessary subtickets and multi second delays moving around the web interface.

core-questions 6y ago

Yes, it's slow as balls. I run my own Jira for ~100 users and, despite throwing as much hardware at it and its PostgreSQL database as possible, it's still extremely slow clicking around and trying to use it. Database operations that would have been fast against simple MySQL 15 years ago on a single core server take seconds. What is it doing that makes it so slow?? The PostgreSQL server has most of the working set of data cached into 64GB of memory, for pete's sake, and still it's not enough to make it fly. Cloud Jira is unusably slow in comparison, too, and when the Atlassian server licenses are not available any more (soon!) and we're forced with having to migrate, I'm not sure what to do. Bite the bullet and just accept the abysmal performance for an easy migration, pay through the nose for the Data Center license, or get people running on a new tool?

probably_wrong 6y ago

> Atlassian seems to make a lot of money, so I guess they're optimising for something that matters to someone My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think. You don't like that the ticket form has 50 fields you don't need? No problem! All you need to do is to convince your manager to contact support and tell them to track less data about your progress. I bet your manager will love that. And once they got the foot on the door, who is going to convince the company to migrate away from them?

xxpor 6y ago
>My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think. That's all enterprise software in a nutshell. And a huge reason why things like Slack and Trello became so popular. They targeted users first without having to get the enterprise to buy it up front.
- toper-centage 6y ago
  I think trello is fine. Its so simple and fast and not trying to overachieve. Or did Atlassian already screw it up?
  - npunt 6y ago
    Not really, but they did recently migrate the login to Atlassian so what was once a quick one-step process becomes a multi-page, multi-redirect mess.
ccwilson10 6y ago
I honestly wish it was that simple for us but convincing management is a fairly sales-driven approach and our marketing model is heavily self-serve. We do have a product called Jira Align that's targeted closer to what you're describing. I'd attribute more of the spread to the concept of "Jira is the defacto" fwiw. Chuckled at convincing managers to track less data. Internally we subscribe to a "less is more" approach and try to limit required fields as much as possible. I bet we feel more willing to contact Jira admins to make changes, though, since we own the product itself. Concur that migrating away from Jira is tough and probably helps keep people in the ecosystem. I haven't met anyone at Atlassian, though, who ever wanted that to be the reason why people stay. I think Jira can be awesome when it's set up well but some stakeholders can get a bit, uh, heavy-handed when deciding on "the process".

kwertyoowiyop 6y ago

It has that slowness that makes my soul die a little every time I bring up a page, every time I click on a link, every time I make an edit, every time I... What’s the opposite of “delightful”?

_Understated_ 6y ago
> What’s the opposite of “delightful”? Unpleasant?
Tempest1981 6y ago
Painful?
3np 6y ago
Delightless
muststopmyths 6y ago
>What’s the opposite of “delightful”? deleterious fits in an alliterative way
SoylentYellow 6y ago
excruciating
maest 6y ago
Lightful?

imbnwa 6y ago

Its a poorly optimized Angular app IIRC

anonymousCar 6y ago
I have no metrics in the frontend, it's reasonably fast for me. It's the interactions with the backend that are slow. This is evident for anyone that's used the api.
- nicoburns 6y ago
  Typing in the description field of a ticket lags and spins up the fans on my laptop. It's doing something wrong.
  - mgkimsal 6y ago
    Unrelated, but... we've got a jira input field that keeps moving the cursor to the end of the input field on each keypress. Perhaps that all do that(?), but it's noticeable when I'm pasting in a URL and want to change the beginning part of the URL. Example: server-abc.example.com, need to change to server-def.example.com - changing the A then moves the cursor to after the .com, which is also beyond the end of the input box, and thus invisible.

waiseristy 6y ago

A customer I am currently working with has a JIRA instance which literally, looking at the firefox network inspector right now, takes 13.04 seconds before it's done loading. It takes at least 10 seconds before the page will even let me scroll. I can't even comprehend how they have managed to get this poor of performance.

Liskni_si 6y ago
Does it keep reloading batch.js? Is it because the URL is changing or is it just not getting cached at the browser? Answering these questions is a first step to speed up Jira. See also my comment from 2018: https://news.ycombinator.com/item?id=18511497 https://news.ycombinator.com/item?id=18511497
- jiggawatts 6y ago
  This is like web optimisation 101. What you did is a clever workaround, but it shouldn't be necessary! Why isn't the Jira server sending compressed content in the first place? If those javascript files are static, they could even cache the compressed versions for extra speed!

Karunamon 6y ago

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.

systematical 6y ago

This is my biggest gripe. It's slow and clunky. Confluence is also terrible (slow and clunky). Mkdocs, which is markdown powered, is much better for documentation. My remaining issues with jira are not with jira at all. Jira can fix its slow ass software, it's feature backlog and I can use mkdocs over confluence. Jira can't fix poor project requirements and management. How fucking dumb are you if you can't even write a bug report? It's what happened, what I expected, and a how to reproduce bullet list.

pigeonbacon 6y ago

Do you know that this post is actually breaking the JIRA ToS? Seriously, it's in their ToS that you can't complain about how slow JIRA is... > Except as otherwise expressly permitted in these Terms, you will not...(i) publicly disseminate information regarding the performance of the Cloud Products https://www.atlassian.com/legal/cloud-terms-of-service https://www.atlassian.com/legal/cloud-terms-of-service JIRA sucks

Kwpolska 6y ago
The OP never stated they’re using it on Atlassian’s cloud, and Jira is available for on-premises deployments too, where those terms don’t apply.
bombcar 6y ago
This is phenomenally hilariously bad, but quite common (I believe Oracle has a "no benchmarks" clause).

dan-robertson 6y ago

See also, a comment from someone who worked on JIRA: https://news.ycombinator.com/item?id=25212441 https://news.ycombinator.com/item?id=25212441

antaviana 6y ago

> Atlassian seems to make a lot of money Atlassian has been losing money in every quarter for quite a few quarters. But its market capitalization has been generally increasing so shareholders who sold their stock probably made money.

frombody 6y ago

Jira is typically not slow. It's usually the plugins you have installed. Some plugins like big picture even have their own databases that need to be updated separately from the plugin, and can cause performance issues. Start jira in safe mode and check the performance. Then check your plugins one at a time until you find the culprit. They also have some nice built in tools that often help you find the source of these problems. It's a product, but it's also a platform, and sometimes the stuff that is built on the platform causes the platform to buckle.

GoldenStake 6y ago

Slow, unresponsiveness, and worst of all lagged resizing caused my biggest daily annoyances in Jira. Several times a week, I click a task, and just want to click the link to an associated epic, or something. But that link keeps dipping and dodging my mouse. I joined another team which used Asana, and it's much better, although certain things can still be slow.

nikau 6y ago

> there's one huge one: It's slow. Really, really slow This is spot on. Its the same reason I hate Sharepoint - every implementation I've used was always incredibly slow, so I would only ever use it when my arm was forced. I miss old school "legacy" style apps that cached stuff so moving around the app is quick. Even simple apps like slack suck these days as it always takes a few seconds to move around windows, why the hell can't it cache things? IRC clients in the 90s did about the same amount of stuff and they never lagged swapping servers or channels.

redisman 6y ago
I would guess because in slack the history can change when irc is basically a read only log. Slack has threads, edits, deletes and emojis etc. that will change the history so you can’t cache it
- nikau 6y ago
  I would prefer slack to update the channels in the background rather than on demand when I click a channel to view. This would probably be a bit more resource intensive, but I have network and CPU bandwidth to spare.

leokennis 6y ago

A year ago, for backlog management we migrated from JIRA to ServiceNow. You don’t know how good you have it with JIRA.