Live data from Hacker News

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

atlassian.com

191–200 of 305 posts

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

#191

Earlier quoted context omitted.

What gateways have you been using?! That's a long, long way off on the modern internet. Assuming you mean gateways as in the lines you'd see on a traceroute, more typical might be ~2-5ms on a home router, ~0.5-1.0ms upstream.

Lol, wasn't expecting that :p Ocelot would be a better example of an gateway https://github.com/ThreeMammals/Ocelot Used for scaling up web traffic or creating bff's ( backends for frontends)

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 that this _is_ backend processing time, not inherent or unoptimisable overhead. e.g. it's totally feasible to do auth checks without making any async calls, just need a bit of crypto and to allocate some memory for tracking revoked tokens - does add a bit of complexity, but likely worth it for the super hot path.

BFFs would not really need to add anything beyond ~1ms or so, but you do hit the lowest common denominator - in that you have to wait for the slowest thing to complete, even if everything is happening in parallel.

BFFs definitely benefit in simplifying client-side code, but at the downside of increased overall latency and potentially resilience which could be achieved by decoupling unrelated components.

As such, I wouldn't expect the Atlassian products to use BFF patterns - for them it's better to throw 1k requests down a single HTTP 2/3 connection and render each part of the page when it's available. I have heard their FEs are very complex, which I think would probably support that assessment.

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

#192

Earlier quoted context omitted.

a) That's not the reason. b) Rate limiting is practically mandatory in an era of multi-gigabit client network connections on even mobile phones. Remember: It's not a DDoS attack if it's one user .

Well, an "average" HN user may use something like a load testing tool such as https://github.com/loadimpact/k6 or at least rent a few VMs with 10Gbps links for a few hours and use wrk/ab so I would not be so sure about (a). Edit: oh, and then they might dust off that Kali Linux VM lying around somewhere...

Which ought not to matter if you use a CDN and use basic source-IP based rate limiting.

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

#193
post #94

Earlier quoted context omitted.

Not who you are respondin to but some thoughts 1. Don't be Slack / Teams :) What I mean by this is if you support it, support it correctly rather than "markdown as keyboard shortcuts" that some products do where if you make the simplest of editing changes, your "markdown" isn't recognized. 2. Devs want to consistently use Markdown across their entire suite At my last job, we were switching to Azure DevOps. They suppo…

Thanks for the detail! Point (1) is very interesting on (2) -> it sounded like you're saying (a) 'across entire suite identically is good', but that also (b) 'if there's a clear separation of Dev vs nonDev apps/docs, having different support is okay', did I read that right? please correct me if wrong.

The correct answer here: use the same editor in the entire suite, everywhere. Give the user a setting to decide if they want that editor to be WYSIWYG, or markdown.

In my personal opinion, Atlassian's rich text editor (or, seemingly, the 4-6 different one's you guys have built) is unforgivably terrible, so true markdown is the way to go if having both isn't an option.

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

#194
post #188

Earlier quoted context omitted.

Hi michaelt, Thank you for the numbers -> I agree these are slow, and I can guarantee you that the Jira team is working on it (though I can't talk about details). These numbers are definitely outside of the goals. I appreciate the call out of "page to complete rendering and the progress bar at the top of the screen to disappear" and "until the issue, comment and buttons have all loaded". In a dream world of course, e…

"'(a) paint faster vs (b) interactive faster'" It is only a tradeoff if you're at the Pareto optimality frontier [1] for those two things. I seriously doubt that you are. You should absolutely be able to have more of both. I would recommend to you personally two things: Open the debugger, and load a page with an issue on it in any environment. Look at the timeline of incoming resources, not just for how long the tota…

I guess I meant that in a more general sense: prioritization is always about tradeoffs, and sometimes you're improving one (paint faster) or improving the other (interactive faster), sometimes both, sometimes trading off one versus the other.

We have looked into the network issues and some of it is similar to what you stated, we do have a known minimum given our chosen cloud infrastructure (separate from our software performance) - we obviously recognize we're not at that limit yet either though.

I have not tried what you mentioned above (load from disk), but I will give it a shot -> it may also give us a clue on how to make our performance testing lower variance, come to think of it......

(apologies for slow replies, HN is still throttling me due to downvotes)

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

#195

Earlier quoted context omitted.

Thank you for coming back and clarifying. Do you happen to have links to any public testing results of other tools, or guidance to this specificity - would love to use them to build a case internally Most of what we've seen online are nowhere near this level of detail (X-ms for Y-%ile for Z-type of load) (edit: clarified request)

I'm afraid I'm no expert on project management tools! On what users experience as effectively "instantaneous", that's from experience on UX engineering and industry standards - https://www.nngroup.com/articles/response-times-3-important-... On the other noted times, they're just a general range of what can be expected from a reasonably well-built tool of this nature. Obviously much simpler systems should be drastical…

Thanks for the link! Yes this is the general guidance we're using too (0.1/1/10s), and one that we're reinforcing at every level of the company. This link does have more detail than I've seen in other places though, so it's an interesting read.

However I've not seen guidance on whether these should be P90 or P95 or P99 measures for example though. We've selected something internally, but obviously selecting amongst three 'measurement points' could drastically change general user's experience.

(HN is throttling my replies so apologies for delay)

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

#196

Earlier quoted context omitted.

The topic of poor Jira performance came up yesterday, and I did some quick benchmarking of Jira cloud using the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, no web proxy, no plugins, same geo region as the servers (Sydney), gigabit fibre internet(!), etc... I spun up a free-tier account and created an empty issue. No data. No history. Nothing in any form fie…

And if you are on battery only, with Wi-Fi over tethering, try to find relevant issues to solve problems of your customer... Or trying to file new Jira on the same setup... It’s so painful

In another YC News thread I was confused by people complaining about their text editor or IDE latency, because I've never had that problem with any editor, despite being a gamer and very sensitive to even tens of milliseconds latency.

A lot of people explained that they do development using a Macbook Air on battery. Those are an order of magnitude slower than a plugged in desktop PC. Twenty milliseconds for me is a two hundred milliseconds for them!

Similarly, many outsourced developers are forced to work on cloud VMs that are not only relatively low-spec (1 or 2 cores), but outright throttled, such as the B-series Azure VMs.

Web developers at ISVs like Atlassian are also "spoiled" by having essentially unfettered LAN connectivity with 1-5 millisecond latencies. Worse still, they'll do development with the server component running on their localhost, which is basically cheating.

Real enterprise networks have at least two firewalls between end-users and the Internet, and at least one web proxy, which more than likely supports only TLS 1.2, HTTP 1.1, Gzip, etc...

We have customers that have less Internet uplink bandwidth for 15,000 users than I have for myself at home.

But all of this is immaterial to Jira's performance woes. It's slow in all circumstances. There is no way to make it fast. Not even liquid nitrogen cooled Zen 3 CPUs running at 8 GHz could bring the page load times down to what I would categorise as acceptable.

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

#197

Earlier quoted context omitted.

Hi michaelt, Thank you for the numbers -> I agree these are slow, and I can guarantee you that the Jira team is working on it (though I can't talk about details). These numbers are definitely outside of the goals. I appreciate the call out of "page to complete rendering and the progress bar at the top of the screen to disappear" and "until the issue, comment and buttons have all loaded". In a dream world of course, e…

I hate to pile on a thread where you're already taking a lot of flack, but this point is really important to the future of Atlassian: > In a dream world of course, everything would load in As a contractor, I have more or less walked out of or refused interviews on discovering Atlassian toolset was in use. It's not because I hate your tooling (it is visually nice and very featureful), it's because the culture that del…

> Your page budget should be 100ms max, given all your tools actually do are track a couple of text fields in a pleasing style

Yeah although it doesn't exactly help in figuring out how to resolve, I think this can be a good grounding in what the product fundamentals actually are and figuring out which over-engineering of those fundamentals is translating into speed problems

I often feel that product people view this type of problem in the wrong way - when you're starting at 5-10s, little incremental A/B tested tweaks are not going to get you down to 50-100ms. A 100x diff requires you to rethink from first principles - it's impossible to get there otherwise

Of course this is also why incumbents get disrupted by startups!

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

#198

Earlier quoted context omitted.

Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ? (edit: looks like HN is severely limiting my reply rate so apologies for delays) We're trying to focus on frustrating pages/experiences rather than number…

I did a test for you just now. I have 100Mbps internet, 32GB RAM, 4ghz i7 processor and suchlike. To make it easy for Jira, I'm doing this at a weekend, late at night, during the new years holiday so the servers shouldn't be busy. On a cloud-based classic software project (which has less than 200 issues) opening a link to an issue it takes 4.8 seconds for the page to complete rendering and the progress bar at the top…

whats hilarious is that the most very basic testing by atlassian themselves reveals these problems. They are a dumpster fire. Trello surely on the same path.

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

#199
post #190
post #85

This is not surprising: anyone who’s used Atlassian products knows that quality has been job number 97 for years. That doesn’t happen by accident – someone’s made the decision that they’ll make sales anyway and cut the QA budget. One of the most obvious examples: they have multiple WYSIWYG editor implementations which aren’t compatible. When you format something in Jira it’ll look fine in the preview and then render…

This is even worse than the crazy slowness. I spend 10 minutes to make a detailed bug report, just to have it fall apart after submitting. How does that happen in a software made to show bug reports? Just use standard markdown instead of your own bullcrap formatting that doesn't ever seem to work.

Best I can say here (as a Confluence PM not a Jira one, and in a public forum) is that customers are not the only ones that experience this pain, and the appropriate folks are notified on a regular basis.

I think the genesis of this is historically many different editable fields might had different modules behind them (not every single one a different one, but maybe a handful of common ones). It looks like for whatever reason we (Atlassian) haven't fully migrated all of them to the newest common editor modules -> I don't know anything for sure though

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

#200
post #20

If you start using Linear you won't need a benchmark to notice the difference. This is what happens when the "clueless" start "innovating". I've had several conversations over the years with members of Atlassian technical teams. They always wanted to work on performance, but never allowed (priorities). They are in "good" company (Oracle, China, etc.). What's preventing anonymous performance benchmarks, though?

Linear works great on chrome for me, but trying to use it on Firefox, it's hopelessly broken. Clicking 80% of things does nothing.
Post reply on HN