Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

atlassian.com

Post reply on HN
Print view View original

271–280 of 305 posts

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#271

Post by rswail »

confluence_perf wrote: post #206
acdha wrote: post #203

Earlier quoted context omitted.

I mean, it really is everything. If it were my project I’d make sure I have telemetry on all UI actions and would then set a threshold (say 200ms), triage everything which has a percentile consistently over that threshold to look for easy fixes, and then set a policy that each release only improves on those numbers. I can’t think of any user-visible changes to Jira or Confluence in the last 5 years which I wouldn’t t…

Hi acdha, Thank you for the advice - how about on the page load side? Our biggest problem is probably the variance issue (mentioned in other subthreads) -> we can't easily tell what is the difference between a slow and a fast load in many cases. Even if we compare things that are available from the metrics like CPU, Mem, and Network speed, those are not very granular metrics (for example, to understand someone with 1…

I'm sorry, as a JIRA user since 2008, your software has always been slow. I used to like that I could run your software on prem and configure issue fields etc, but now, you have so many layers of crap and "pretty" that its not suprising you can't tell what is fast and what isnt.

It is not your customers job to instrument your software. Your API gateway can provide precise and accurate figures on how long API calls take and there is nothing stopping you adding web page metrics that can provide client-side measurements as well.

Some examples are available on the publicly visible JIRA boards, like the one for hibernate. Just go click on all issues and then click on any issue in a private browser window and with the cache empty.

Every one of the fields take seconds to load. That is not internet roundtrip time, that is your backend. Even when the issue is ~80% loaded (according to your own page load bar), there are still JS scripts that will load and reformat the page, causing the browser to reflow.

These are not cached, because loading another issue doesn't resolve the problem.

So there are fundamental front end problems that have nothing to do with the servers or backend, they are entirely a problem of the JS and the in-browser activities.

Fix them.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#272

Post by Noumenon72 »

throw_jirauser wrote: post #160
confluence_perf wrote: post #136

Earlier quoted context omitted.

Hi lostdog, Thanks for the understanding! Indeed I haven't been at Atlassian that long, but that's not a good excuse: it's my problem to own. I appreciate the reinforcement of "fix everything", and I assure you we're trying our best to do so. As a PM it is my natural instinct (and literal job) to prioritize, so I'm always looking for more details to do so. I can understand that my request for details can imply that I…

This is a throwaway since I use Jira/Confluence at work and am not authorized to officially speak on their behalf. We are actively looking for other solutions outside of Atlassian, specifically because the demands to switch to your cloud offerings. We simply do not trust your cloud. We also have a higher compliance requirement, since we can have potential snippets of production data. Our Jira/Confluence systems are h…

Same, government contractor can't use cloud Confluence, and the performance is so much worse, why would you? On-prem is so snappy it's comparable to using Word. I evaluated cloud for my previous company in 2018 and performance was the dealbreaker.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#273

Post by EdwardDiego »

dreamcompiler wrote: post #168
dalrympm wrote: post #22

I'm curious, I'm a Cloud customer and I can tell you that the service is incredibly slow even for a small scale setup (2 Jira Projects and 3 Confluence Workspaces). There's an insane amount of network requests seemingly for mouse tracking. By telling everyone here, that Atlassian Cloud products are insufferably slow, am I violating the ToS? I was actually thinking about doing a write up on the issues I've had but thi…

I'm very curious about where the slowdown is coming from. Is it mostly JS on the client or Java on the server? When I ran my own Confluence server on a Digital Ocean VM, it was slow but not unbearable. I assumed it was Tomcat's fault* or the fact that I wasn't using a "real" database on the backend (a configuration Atlassian frowns upon). *Confluence is built on Tomcat. Don't know if this is also true for Jira. Now t…

Tomcat is fast, unless you do slow things synchronously.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#274

Post by jauer »

NicoJuicy wrote: post #251
BillinghamJ wrote: post #191

Earlier quoted context omitted.

Ah nice, I didn't realise you meant application proxies/gateways. Network ones are so quick due to their ASICs etc! I personally would still say 50ms is super, super slow for an application gateway - a well designed one using e.g. nginx/openresty, lambda@edge, or simply writing another application server etc can easily do that job with an addition of If it is e.g. making a DB request to check auth, I would highlight…

Ocelot - localhost => 40-50 ms on a workstation. Gateways can add a lot of functionality. Even Graphql can be used as a gateway. It's not all "dumb forwarding" and I would be very surprised that you find any sub ms benchmarks. Amazon has a one million dollar award if you get the page to load under 10 ms. So that's what you are expecting by default on a saas in your previous comment. It's still unrealistic.

That just says that Ocelot consumes quite a bit of your latency budget. Maybe the features it brings are worth it to you, but it's def not anywhere close to the limit of what's achievable.

e.g. Envoy (which replaced Ocelot in Microsoft's .net microservice reference architecture) has a significantly lower latency cost (1)

Your reference to an Amazon reward is interesting as it's quite easy to get pages to load under 10ms in the right conditions. Perhaps you can provide a link to more information?

1. https://docs.microsoft.com/en-us/dotnet/architecture/microse...

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#275

Post by Too »

fphhotchips wrote: post #214
BillinghamJ wrote: post #138

Earlier quoted context omitted.

> In a dream world of course, everything would load in It's important you understand that "everything loading in That is not "a dream world" - not even close. A well built tool like this, meeting standard expectations (i.e. table stakes), would hit You should be targeting This is why people are saying the company needs to make a major shift on this - you're not just out of the ballpark of table stakes here, you're ba…

Do you have evidence that what you're asking for is possible? I'd be interested to see websites that hit the benchmark that you're aiming for. I just tested a HN profile page (famously one of the lightest weight non-static websites) and it takes between 300ms and 600ms to load. I'm not saying that Jira can't improve, but if HN isn't hitting 250ms then I think telling the Jira guys that nothing less than <200ms is the…

Look at github pull requests. It loads in under 200ms for me. And is vastly more complex than HN, both in sense of queries and UI, content should be equivalent of what Jira needs.

Jira is also much more interactive than HN. You are sitting 10+ people in a room with some half asleep scrum master opening the wrong issue, have to go back and open the correct one, search again for some related issue you though was fixed last month. Refresh the board to make sure you didnt forget to fill in one field so it ends up in the wrong column, etc etc.

1 sec per click in a situation like this is a joke, and that's just their goal. Reality is 4sec+ as OP mentioned, often even more.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#276

Post by maccard »

guitarbill wrote: post #268
maccard wrote: post #88

Earlier quoted context omitted.

As awful as confluence is, it's not really a mediocre wiki. It's the best I've used. (Out of confluence, notion, mediawiki and some god awful internal thing based on wordpress). It's interface sucks, the performance sucks, the editor sucks, search sucks, and it's still the best.

Point still stands, right?

I don't think so. If it's mediocre, then it's mediocre compared to something else, but in reality it's best-in-class. It just turns out that the opposition isn't exactly bringing it's a game.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#277

Post by chrisandchris »

jchook wrote: post #225
dalrympm wrote: post #22

I'm curious, I'm a Cloud customer and I can tell you that the service is incredibly slow even for a small scale setup (2 Jira Projects and 3 Confluence Workspaces). There's an insane amount of network requests seemingly for mouse tracking. By telling everyone here, that Atlassian Cloud products are insufferably slow, am I violating the ToS? I was actually thinking about doing a write up on the issues I've had but thi…

Check out Clubhouse.io I've used many others including Github, GitLab, Phabricator, Redmine, etc., and Clubhouse does a great job IMO.

Is there an on-prem version?

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#278

Post by chrisandchris »

mattm wrote: post #122
emilfihlman wrote: post #81

Earlier quoted context omitted.

This is just awful

As a software engineer who has been woken up in the middle of the night while oncall because some random user wanted to run their own performance tests against our system, I can completely understand why companies want to prevent this from happening without their awareness.

I agree but there‘s a major difference between benchmarking a tool and writing about how slow a tool is. I agree with the first being forbidden, but the lather should be allowed.

For Atlassian Cloud, you won‘t beed a benchmark to tell it‘s slow. A simple (physical) stopwatch is enough.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#279

Post by samb1729 »

magicalhippo wrote: post #263
samb1729 wrote: post #261

Earlier quoted context omitted.

I’m relatively sure it’s the lack of several host to host hops in the network requests that makes an on-prem install so much faster. The way Atlassian’s hosted services handle requests is mind-bogglingly awful and necessitates several round trips per request a lot of the time. It’s just poor architecture on their end. We’re talking 3-5 redirects for some things they could just proxy on their backend. It’s dumb and th…

This should be quite glaring in any performance metrics collected though, shouldn't it? I mean, I don't do web stuff (yet) but I can't imagine it's that difficult to figure out where several seconds get spent.

It’s possible that Atlassian work culture requires getting permission to grant permission to a subordinate to grant permission to their subordinate to do some work, contingent on a report of the quantifiable metrics that will be reported periodically to be compiled into other periodical reports that no one will care enough to read.

I’m only sort of joking here, since it can be weirdly difficult to actually just do the job you’re being paid to do in some orgs. I once got paid handsomely to deliver almost nothing for six months since all the layers above me were busy either talking back and forth or not even caring at all. It bored me so much that I had to leave, but the money was great.

There weren’t even any disappointed customers because they just allocated budget and forgot about the project. It wasn’t their own money they were spending, after all.

Being an engineer is weird sometimes.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#280

Post by BillinghamJ »

ZephyrBlu wrote: post #256
fphhotchips wrote: post #214

Earlier quoted context omitted.

Do you have evidence that what you're asking for is possible? I'd be interested to see websites that hit the benchmark that you're aiming for. I just tested a HN profile page (famously one of the lightest weight non-static websites) and it takes between 300ms and 600ms to load. I'm not saying that Jira can't improve, but if HN isn't hitting 250ms then I think telling the Jira guys that nothing less than <200ms is the…

200ms for user interactions is different to a 200ms page load. A 200ms page load is incredibly fast. Still, I tested your profile page on Google PageSpeed and it came out at a 300ms load time. https://developers.google.com/speed/pagespeed/insights/?url=...

Assuming the FE resources are already cached on the user's machine, with careful optimisation, doing all of the rendering/fetching on the FE over a single connection, and with everything parallelised, it definitely is possible to load a new page well under 100ms with the key content being displayed.

When taking that kind of approach, you don't have to wait for the slowest thing to come in - eg with a normal BE render, you might need to pull up the user's profile and settings, A/B testing flags, the current footer config or whatever.

eg if you're on the page for viewing a single ticket, you can request the ticket data immediately, and render it as soon as it's available - even if other parts of the page aren't finished yet. True it may be more like 200-300ms to have the entire thing be 100% complete, but all parts of the page are not of equal importance and holding up the main content while loading the rest isn't necessary.

If you are doing a full BE render, it's still totally possible to hit that 100ms mark, but indeed dramatically more difficult.

Post reply on HN