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

141–150 of 305 posts

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

#141

Post by confluence_perf »

BillinghamJ wrote: post #138
confluence_perf wrote: post #115

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…

> 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 times' in Confluence, so most conversations center around that)

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

#142

Post by Macha »

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…

It's hard to name a single action I can take in JIRA which does not feel unacceptably slow. However, these are the actions that cause the most issues for me due to being used most often (JIRA datacenter, MBP 2019 with i7 + 32gb ram):

1. Viewing a board. This can take 10+ seconds to load.

2. Dragging an issue from one column to another. This greys out the board, rendering it unreadable and unusable for 5-ish seconds.

3. Editing a field. I get a little spinner before it applies for 2-3s for even the simplest edits like adding a label.

4. Interacting with any board that crosses multiple projects. A single project board is bad enough, as in point 1, but we have a 5 project board that takes 20+ seconds.

Actually, I found an action that's pretty ok: Search results are fast, even if clicking into any of them is not. I'm not sure why rendering a board is so different performance wise.

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

#143

Post by cosmotic »

Most if not all users of these applications aren't even in the position to review or accept the terms. When I was subjected to the terms dialog, I asked our legal department what I should do since obviously I am not an agent of the company. They said 'just click accept'. Unbelievable.

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

#144

Post by confluence_perf »

Macha wrote: post #142
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…

It's hard to name a single action I can take in JIRA which does not feel unacceptably slow. However, these are the actions that cause the most issues for me due to being used most often (JIRA datacenter, MBP 2019 with i7 + 32gb ram): 1. Viewing a board. This can take 10+ seconds to load. 2. Dragging an issue from one column to another. This greys out the board, rendering it unreadable and unusable for 5-ish seconds.…

Thank you so much for the details! This is very helpful. I will pass this along to my Jira Perf colleagues (there's multiple of them, since they know Perf is such a big issue).

Just to clarify on Search though, which search are you talking about:

a) quick search (top bar) b) issue search (the one with the basic/JQL switcher) c) something else

Trying to narrow down the latter "even if clicking into any of them is not" part to understand which view that is

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

#145

Post by lostdog »

confluence_perf wrote: post #129
skrap wrote: post #111

Earlier quoted context omitted.

If you want to make performance a feature, you need to (in order!) * define a metric * measure it automatically with every commit * define a success threshold * make changes to get yourself under the threshold * prohibit further changes which bring you above the threshold Just do it like that for pretty much every view in the system.

As recommended by another poster to take advantage of the technical community here, I have one question and one comment if you can provide more insights: question a) My understanding is that performance numbers fluctuate a LOT, even at sampling in the tens of thousands. Do you have any recommendations of tools or methods to reduce this variance? comment b) we're definitely trying to do this but we're not there yet -…

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 the barrier soft. If the performance tests break the threshold, then you need to get signoff from a manager or senior engineer. This way, you can continue to make coding progress while adding just enough friction that people are careful about making performance worse.

The second problem of high variance is showing that you're making progress. However, for you, this isn't a real problem. You're not talking about cutting 500 microseconds off a 16 millisecond frame render. You need to cut 5-25 second page loads down by a factor of 10 at least. There must be dozens of dead obvious problems taking up seconds of run time. Is Confluence's performance so atrocious that you couldn't statistically measure cutting the page load time in half?

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

#146

Post by pacamara619 »

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…

Is this bait?

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

#147

Post by Macha »

confluence_perf wrote: post #144
Macha wrote: post #142

Earlier quoted context omitted.

It's hard to name a single action I can take in JIRA which does not feel unacceptably slow. However, these are the actions that cause the most issues for me due to being used most often (JIRA datacenter, MBP 2019 with i7 + 32gb ram): 1. Viewing a board. This can take 10+ seconds to load. 2. Dragging an issue from one column to another. This greys out the board, rendering it unreadable and unusable for 5-ish seconds.…

Thank you so much for the details! This is very helpful. I will pass this along to my Jira Perf colleagues (there's multiple of them, since they know Perf is such a big issue). Just to clarify on Search though, which search are you talking about: a) quick search (top bar) b) issue search (the one with the basic/JQL switcher) c) something else Trying to narrow down the latter "even if clicking into any of them is not"…

Doesn't Quick Search lead into issue search when you press enter?

I think I mean issue search.

By clicking into them, I mean actually loading the issues is slow.

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

#148

Post by confluence_perf »

lostdog wrote: post #145
confluence_perf wrote: post #129

Earlier quoted context omitted.

As recommended by another poster to take advantage of the technical community here, I have one question and one comment if you can provide more insights: question a) My understanding is that performance numbers fluctuate a LOT, even at sampling in the tens of thousands. Do you have any recommendations of tools or methods to reduce this variance? comment b) we're definitely trying to do this but we're not there yet -…

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 it's measurable at volume for sure, and even in testing.

The main issue is "degradations" -> catching any check-ins that can degrade performance. These are usually small individually (lets say, low double digit MS) within the variance noise), but add up over time, and by the time the degradation is really measurable, its complicated tracking down the root cause. Hopefully I described that in a way that makes sense?

Any suggestions welcome.

(Edit: downvoted too much and replies are throttled again) ----@lostdog Thanks for the detail! will definitely take this to eng team for process discussion.

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

#149

Post by petters »

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…

Initial loads should definitely be be But Jira currently is so slow that 1s would be a great improvement. I am using it at work and regret it, unfortunately.

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

#150

Post by BillinghamJ »

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…

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 interactions as being effectively instantaneous. So it really is worth setting a super high bar as your target here (esp given you need a bit of breathing room for future changes too).

Post reply on HN