Hacker News new | ask | show | jobs
by magicalhippo 330 days ago
> Turns out when you eliminate all network latency, things get snappy.

Same experience with JIRA. I read all these negative comments here and elsewhere about how slow and clunky JIRA was, and I couldn't relate at all.

Then I realized all those who complained was using JIRA Cloud and we were using on-prem, and it all made sense.

We've since moved to JIRA Cloud ourselves, and I understand now.

We moved and none of the new places had any viable computer room, so literally had to put the rack in a closet And well, that ain't cutting it for physical access control these days. Thankfully we have very simple flows without any BS, so not too many 1-5 second clicks to get things done.

11 comments

Just open the network tab and refresh a page in Jira and you will understand. It isn’t too noticeable on a LAN. Stick the internet in there and it is painful. The worst I have seen is self hosted and accessed over Netskope ZTNA. Truly an abomination.
It's not the refresh that screws you. It's the four goddamn dozen asyncrhonous calls it has to make after that refresh has completed to actually fill out the content of the page and let you click through stuff.

I have to load half a dozen tabs of new tickets and then cycle through them triaging and defining fields in a collated manner to make it so my time isn't hugely dominated by waiting.

We used to have on-prem and it was probably about an order of magnitude better, but still nowhere near "XP in a VM accessing a site on localhost" level snappy.

LAN? What about WFH?
> We've since moved to JIRA Cloud ourselves, and I understand now.

Jira on-prem was dog slow, yes, especially if it didn't live on the same server as the database. But Jira Cloud? It isn't much faster than that! It's a piece of hot mess. Loading placeholders everywhere. Really I have absolutely zero idea what Atlassian is doing, but I know for sure optimizing for performance is not amongst the things they are doing.

Yeah, this whole pattern of loading a million placeholders and then watching the page awkwardly snap into layout is just sad. Especially when you know that you could have shown just as much information in a "server side rendered" piece of PHP in 2005 with less latency.
That would be Redmine.
I have had the opposite experience with Jira at a relatively large corporation (years ago). Our local Jira was probably just configured weird or on underpowered hardware though.
Having adopted a number of development tools, including Jira and Confluence, it’s amazing people let them sit there chugging away on underpowered machines with hundreds of users quietly complaining about the speed. Throwing some extra CPU cores and memory is so cheap for the quality of life improvement, let alone the productivity gain.
The concurrent (human) user counts at even large companies is probably a couple dozen at most.

Usually with these tools, the performance problems magically vanish if you disable all the integrations people have set up. My company is constantly denial of service attacking Jira with Github updates, for example.

Edit: typo

I delivered a complex, highly customized enterprise back-office system for a large Fortune 500 some time back. It involved a handful of servers (all as VM's), x3 to accommodate DEV/QA/PROD staging.

It worked great in volume testing in our environment. Their IT department installed it on high end servers (hundreds of cores, incredibly expensive storage subsystems, etc) but users complained of latency, random slowness, etc. IT spent weeks investigating and swore up and down it wasn't their end and must be a software issue. We replicated and completely sanitized production volumes of data to try and recreate locally and couldn't.

Finally I flew down and hosted their entire infrastructure off my laptop for a day (I'll skip all the security safeguards, contract assurances, secure wipes, etc). It flew like a thoroughbread at a racetrack. No latency, instant responsiveness, no timeouts, no hiccups. Their entire staff raved about the difference. The results gave the business unit VP what she needed to bypass the usual, convoluted channels, and someone must have lit a fire under their IT VP - by the end of that day their internal techs identified a misconfiguration on their storage arrays and solved the problem. I can only guess how many other apps were silently suffering for weeks or months on the same array. I joked I'd be happy to sell them a laptop or two for a fraction of their mainframe cost.

I had the experience for a few years of having to run all of the self-hosted development and project management tooling for a government project about a decade back, and the integrations part holds up strong to that experience. The CI system that had been put in place was probably the most sophisticated I've ever seen, but that had some unfortunate side effects like Jenkins jobs being kicked off automatically thousands of times an hour, blasting all of the Atlassian tools with network requests, or Nessus remote logging into and spawning 40,000 simultaneous processes on the servers actually hosting the Atlassian tools.

Self-DOSing is exactly what it was.

People complaining about JIRA has become enough of a trope that it mostly gets ignored.

Also big enough corps give underpowered machines to the mass of employees (anyone not a dev, designer or lead of something) so latency is just life to them.

Also that Jira is one of these mutants, between SPA and pages, doing neither well.
I contracted with a company that used an on-prem version of Jira. Their instance was painfully slow over VPN and I often wondered why they didn't add more resources thinking that this was the experience for everyone. Then I went on-site for a few days and the performance was night and day. On-prem, their Jira instance was the fastest I've ever seen, faster than the cloud version and felt snappier than Trello.

On-prem is great if everyone is coming into the office, but I think orgs should pay more attention to the "remote experience" of their on-prem tools.

> Then I realized all those who complained was using JIRA Cloud and we were using on-prem, and it all made sense.

Even Atlassian doesn't use Jira cloud. Btw it's not "JIRA".

> Even Atlassian doesn't use Jira cloud.

That would explain a lot.

> Btw it's not "JIRA".

When did they change this? I'm fairly certain[1] it used to be JIRA.

[1]: https://confluence.atlassian.com/jira061

In 2013, to be specific.
Atlassian very much do use Jira cloud. Source: I worked there for 10 years. Not apologising for it's performance however.
Any inights why the performance often varies between a Model T Ford and a glacial boulder?
I mean, presumably it's subject to the two curses of modern software:-

1. Unless major customers are actively closing their accounts due to the poor performance, improving performance isn't a priority.

2. The people who pay for it aren't the people who use it, so the performance can get very, very bad before customers start closing their accounts.

What a weird time to enforce British rules for acronyms.

JIRA stands for JIRA Isn't Really Awesome.

I always say Janky Irritating React App.
My chucklebone made a guffaw. Thanks!
JIRA Is Really Awful.
True, but I try to stay positive.
But what does the “JIRA” in “JIRA Isn’t Really Awesome” stand for?
Same thing as the “GNU” in “GNU’s Not Unix” — it’s a recursive acronym
Case in point: https://jira.atlassian.com/projects/ Look how snappy it is!
That's no longer the case - a large portion of teams are now using cloud variants of Confluence/Jira.
Everytime I'm using JIRA and I type JIRA and it automatically corrects it to Jira, I hit Ctrl+Z to undo the autocorrect.
My company self hosts most things, which is bad for remote employees and employees in offices other than the primary because the VPN server (or possibly their network connection) is underpowered for the number of remote users. I sometimes need to wait 45 minutes for a like 1GB clone.
Myself included, JIRA is used far too much out of the box and few people ever learn what it can actually do.

Out of the box it is pretty generic. When I learned what it could actually do, it revealed itself as a sponge that can uniquely absorb complexity. Having someone familiar with JIRA show the ropes went a long way.

Some of these new development tools are pretty nice though. Variety is good, especially with the changes from Pivotal Tracker, etc going away.

Our org used Jira on-prem for 2k engineers and 3k additional staff and it was slow as molasses.

The dialogues and context menus took forever to show and page navigation was beyond painful.

We had dedicated engineering for maintaining our Jira and Bitbucket, and they still fell over. We eventually moved back to GitHub. (Our usage went from GitHub on-prem pre-MS -> Bitbucket on-prem -> GitHub cloud post-MS.)

I hate Jira regardless of where it's deployed. It's a beast.

We run a full Atlassian suite on prem for 5k users and it works really well

Well except Bamboo. It’s terrible

We run an airgapped version of JIRA (but we are a very big company, globally distributed). Performance is in the gutter.

The annoying part is the amount of garbage fixes in JIRA's UI. For example, because of the loading speed, and me losing patience with it, if I don't wait for the page to finally finish loading and click on the "create" button, then instead of the modal dialog for issue creation, I get a whole new page for issue creation. Both options are atrocious from UX perspective (because usually I need to copy text from the issue I was reading into the issue I'm creating), but at least when it's a modal window, I can pop open the developer tools and delete the modal part that prevents me from copying the text from the issue otherwise blocked from interaction.

Also, it looks like due to speed, some queries simply don't finish on time, and randomly, searches don't find all the issues they should. Especially searches that ask for "s.t. parent issue has such-and-such properties".

Ultimately, JIRA isn't built to scale (ironically, since it's written in Java, which was always defended as being slow for small problems but scaled well). The code has a lot of assumptions about some operations being fast enough to not require buffering / incremental implementation. And sometimes you hit the combos of such unoptimized operations and have to wait minutes for the program to respond.

The other thing, every pm wants a custom field just for their project, a field they’ll forget they asked for a day later. TLDR, put a governance board that’s fine saying no especially when someone inevitably pulls rank.
Apparently System-scope custom fields have a significant performance hit in Jira. I think project-scope custom fields are better.

Sometimes it feels like Jira is so incredibly configurable but is really missing the "pit of success". There is a way to make it nice to use and reasonably performant, but you really need to go into it with a strong plan. And even then it's really easy to balls it all up in short order if you're not vigilant.