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

161–170 of 305 posts

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

#161

Post by BillinghamJ »

confluence_perf wrote: post #153
BillinghamJ wrote: post #150

Earlier quoted context omitted.

As a first step, 1s would be better than nothing for sure, but you need to be working towards a much tighter goal on a 1-2 year timeframe. New load, you should really be hitting 200ms as your 95th percentile - 300ms or so would be decent still. "Transitions" should hit 100ms 95th, 150ms would be decent. If you did hit 100ms across the board, you'd be rewarded by your customers/users psychologically considering the in…

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 drastically faster, but project management tools do tend to be processing quite a bit of data and so do involve _some_ amount of inherent "weight", but that isn't an excuse for very poor perf.

That said, I imagine if your PMs do some research and go ahead and try using some of the common project management tools, you should get a good idea. ;) Keep in mind speeds to Australia (assuming Atlassian is operated mostly there?) will likely show them in a much worse light than typical perf experienced in the US/UK/EU areas.

The time to first load is derived from the fact that you're running essentially the equivalent of many "transition" type interactions, but they should be run almost entirely in parallel, so roughly 2x between "transition" and "new load" is a reasonable allowance.

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

#162

Post by throw_jirauser »

miken123 wrote: post #112
confluence_perf wrote: post #28

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…

> Would you be willing to share more specifics That's something you could easily figure out yourself. E.g., just grabbing some random JIRA: https://hibernate.atlassian.net/jira/software/c/projects/HV/... Opening an issue in that tracker takes 24 seconds for me. Twenty-four.

31.2 seconds, on a not great internet connection (cell)

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

#163

Post by launderthis »

lmilcin wrote: post #154
michaelt wrote: post #105

Earlier quoted context omitted.

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…

See, the irony of this is that you are just publicly sharing performance numbers which undeniably show a pattern of performance issues. It also doesn't seem to be possible without you first accepting ToS. Ooops!

who says this is an "issue" its just numbers. If you think its an issue thats your interpretation. For instance I used jira for communicate with my team about 3 projects and it only took me 3 hours.

Maybe this person is writing a fiction story where the protagonist is using Jira and they are detailing how they spend their day.

Its like a John Steinbeck novel

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

#164

Post by MattGaiser »

judge2020 wrote: post #14

Cloudflare has this as well: >you will not and you have no right to: ... (f) perform or publish any benchmark tests or analyses relating to the Cloud Services without Cloudflare’s written consent; https://www.cloudflare.com/terms/#react-modal:~:text=(f)%20p...

Are these terms really that nefarious or just a way to terminate some customer who decides to load test your system and ends up bringing it down? Legal documents are typically written to be as broad as possible.

Perhaps it should be more narrowly written, but prohibiting certain kinds of testing without permission is reasonable.

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

#165

Post by marmaduke »

pluc wrote: post #133
plorkyeran wrote: post #51

Earlier quoted context omitted.

Literally everything? I don't think I could give an example of something which isn't frustratingly slow in Jira. It doesn't need targeted fixes to specific things; if I successfully made a list of the ten biggest offenders and they were all magically fixed tomorrow I don't think it'd appreciably change the experience of using Jira because the next 90 would still be awful. When faced with long-tail performance problem…

It seriously makes you wonder whether they even use it internally, because not acknowledging or fixing those issues while pretending you have a fast system doesn't make sense.

Yep, and from a demo of YouTrack (from JetBrains), I got the opposite impression: it’s streamlined just the way a developer would want, keyboard shortcuts and all.

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

#166

Post by lostdog »

confluence_perf wrote: post #148
lostdog wrote: post #145

Earlier quoted context omitted.

The high variance is another problem. Good software has low variance in performance. Especially if you're sampling in the tens of thousands. The high variance does give you two tactical problems. First, how do you keep performance from getting worse? Typically you would set a threshold on the metrics, and prevent checking in code that breaks the threshold. With high variance you clearly cannot do this. Instead, make…

"High variance as a consequence of poor software" is an interesting point and not one I'd considered -> I will take this to engineering and see if we can do anything about that (some components maybe, but we see high network variances too which seem unlikely to be fixable). Showing that we're making progress isn't as much of a problem - similar to what you stated, the fixes themselves target large enough value that i…

I work in an area where high variance is very expected and unavoidable. Here's what we do:

In your PR, you link to the tool showing the performance diff of your PR. The tool shows the absolute and relative differences of performance from the base version of code. It also tracks the variance of each metric over time, so it can kind of guess which metrics have degraded, though this doesn't work consistently. The tool tries to highlight the likely degraded metrics so the engineer can better understand what went wrong.

If the metrics are better, great! Merge it! If they are worse, the key is to discuss them (quickly in Slack), and decide if they are just from the variance, a necessary performance degradation, or a problem in the code. Typically it's straightforward: the decreased metrics either are unrelated to the change or they are worth looking into.

The key here is not to make the system too rigid. Good code changes cannot be slowed down. Performance issues need to be caught. The approvers need to be fast, and to mostly trust the engineers to care enough to notice and fix the issues themselves.

We also check the performance diffs weekly to catch hidden regressions.

IF YOUR ORGANIZATION DOES NOT VALUE AND REWARD PERFORMANCE IMPROVEMENTS, NONE OF THIS WILL WORK. Your engineers will see the real incentive system, and resist performance improvements. Personally, I don't believe that Atlassian cares at all about performance, otherwise it never would have gotten this bad. Engineers love making things faster, and if they've stopped optimizing performance it's usually because the company discourages it.

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

#167

Post by dalrympm »

isodev wrote: post #114
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…

JetBrains recently announced Space and it looks pretty cool (and fast): https://www.jetbrains.com/space/

I'm a heavy JetBrains user but I've found their server side offerings to be lacking. I haven't been a fan of YouTrack in the past but maybe it's time to give them another try.

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

#168

Post by dreamcompiler »

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 that my Confluence server is on Atlassian's cloud, it seems much slower still. So I have to assume it's not client-side JS because that hasn't changed much; there's some kind of resource starvation going on with Atlassian's servers.

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

#169

Post by launderthis »

confluence_perf wrote: post #141
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…

Hi BillinghamJ, You're right, I apologize for not being clear. We're targeting 1s for "Initial loads" on new tabs/new navigation, which I assume you're referring to. Our target for 'transitions' is different. If however the numbers you're referring to are "initial load" numbers, then I'm not sure. (edit: and action responses again are also a separate category. Our largest number of complaints are about 'page load tim…

no dont give into this guy ... this is done over the net. The rate of transfer has to be taken into account. Unacceptable is a measure of comparison.

Unacceptable to who, you have a faster provider for cheaper, with as many features???

Im pretty sure he doesnt because if he could he would go there. There are tradeoffs and Atlassian has many project they are working on. They understand that there is room for improvement in performance. Its one of Atlassian's priorities, it is a tech company (a pretty good one I would say).

I guess one question is about server redundancy. Where is this guy loading from and where is the server he is loading from? Getting things below 1s is nearing the speed of the connection itself. Also at that speed there is deminishing returns. Something that happens at 1s vs .5s doesnt make you twice as fast when you dont even have the response time to move your mouse and click on the next item in .5s.

Sometimes techies just love to argue. You are doing great Atlassian and have tons of features. But maybe it is time to revisit and refactor some of your older tools.

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

#170

Post by dmitriid »

confluence_perf wrote: post #28
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…

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 think this answer from two months ago should give all the insight you ever want: https://news.ycombinator.com/item?id=24818907

And the first answer to your comment in this thread profiling performance for an empty page with almost no data on a small project should give you even more data than you ever would want.

And this one for an empty project: https://news.ycombinator.com/item?id=25616069

However, having personally experienced "upgrades to Jira and Confluence experiences" over the past few years, I can safely say: no one at Atlassian gives two craps about this. All the talk about "We are definitely working on generalized efforts to make 'most/all/everything' faster" is just that: talk. There's exactly zero priority given to performance issues in lieu of flashy visual upgrades which only make the actual experience worse.

> We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority.

Exactly: you aren't even trying to understand what people are telling you. These metrics you ask for and then dismiss entirely are the primary, core, systemic reason for frustrating slow experiences that you pretend are "high priority". No, frustrating slow experiences have not been a high priority for years (if ever).

If you need to do 200 requests and load 27.5 MB of data to display an empty page, therein lies your problem. You, and other PMs at Atlassian fail to understand these basic things, and yet we get platitudes like "performance is our top priority". It is not. You're good at hiding information and buttons behind multiple layers of clicks, each of which needs another 200 requests and 5-15 seconds to execute.

Oh. You're also good at adding useless crap like this: https://grumpy.website/post/0TcOcOFgL while making sure that your software is nigh unusable: https://twitter.com/dmitriid/status/888415958821416960 I imagine all performance tickets get dismissed because no one can see the description even on a 5k monitor

Post reply on HN