8 ms·

> In a dream world of course, everything would load in < 1s It's important you understand that "everything loading in <1s" would still be unacceptably slow - t

> In a dream world of course, everything would load in < 1s It's important you understand that "everything loading in <1s" would still be unacceptably slow - that is still an order of magnitude too slow. That is not "a dream world" - not even close. A well built tool like this, meeting standard expectations (i.e. table stakes), would hit <50ms for the end user - the vast majority of the time. A "dream world" would be more like 10ms. You should be targeting <200ms for 99% of user-facing interactions. That is the baseline standard/minimum expected. 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 barely in the same county! It cannot be overstated how far off the mark you are here. There's a fundamental missetting of expectations and understanding of what is acceptable.

confluence_perf 6y ago
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)
- petters 6y ago
  Initial loads should definitely be be <100ms as well. But Jira currently is so slow that 1s would be a great improvement. I am using it at work and regret it, unfortunately.
- BillinghamJ 6y ago
  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).
  - confluence_perf 6y ago
    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)
    - BillinghamJ 6y ago
      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-limits/ 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.
      - confluence_perf 6y ago
        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)
- launderthis 6y ago
  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.
  - BillinghamJ 6y ago
    You've shown poor understanding here. > Getting things below 1s is nearing the speed of the connection itself That is absolutely false. Internet latency is actually very low - even e.g. Paris to NZ is only about 270ms RTT, and you _do not_ need multiple full round trips to the application server for an encrypted connection - on the modern internet, connections are held open, and initial TLS termination is done at local PoPs. For services like this - as they are sharded with customer tenancy - are usually located at least in the same vague area as the customer (e.g. within North America, Western Europe, APAC etc). For most users of things like Atlassian products, that typically results in a base networking latency of <30ms, often even <10ms in good conditions. Really well engineered products can even operate in multiple regions at once - offering that sort of latency globally. > Im pretty sure he doesnt because if he could he would go there Yeah, we don't use any Atlassian products - partly for this reason. We use many Atlassian-comparable tools which have the featureset we want and which are drastically faster. > when you dont even have the response time to move your mouse and click on the next item in .5s. There is clear documented understanding of how UX is affected by with various levels of latency - https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-... > Sometimes techies just love to argue Not really, I have no particular investment in this - I don't use any Atlassian product, nor do I plan to even if they make massive perf improvements. But I do have an objective grasp - for tools like this - of what's possible, what good looks like, and what user expectations look like. > no dont give into this guy I don't expect Atlassian is going to make any major decisions entirely based on my feedback here, but it is useful data/input for exploration, and I do feel it's right to point out that they're looking in the wrong ballpark when it comes to the scale of improvement needed.
NicoJuicy 6y ago
> A "dream world" would be more like 10ms. A gateway solely adds 50 ms. So I'm not really sure where you get your numbers/benchmarks from... They are unrealistic
- BillinghamJ 6y ago
  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.
  - NicoJuicy 6y ago
    Lol, wasn't expecting that :p Ocelot would be a better example of an gateway https://github.com/ThreeMammals/Ocelot https://github.com/ThreeMammals/Ocelot Used for scaling up web traffic or creating bff's ( backends for frontends)
    - BillinghamJ 6y ago
      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 <0.1ms processing time (assuming no additional network calls or heavy work), and maybe 0.3ms for additional connection establishment if it hasn't been optimised to use persistent connections. 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.
fphhotchips 6y ago
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 minimum standard is unrealistic.
- ZephyrBlu 6y ago
  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=https%3A%2F%2Fnews.ycombinator.com%2Fuser%3Fid%3Dfphhotchips&tab=desktop https://developers.google.com/speed/pagespeed/insights/?url=...
  - BillinghamJ 6y ago
    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.
- Too 6y ago
  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.

confluence_perf 6y ago

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)

petters 6y ago
Initial loads should definitely be be <100ms as well. But Jira currently is so slow that 1s would be a great improvement. I am using it at work and regret it, unfortunately.
BillinghamJ 6y ago
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).
- confluence_perf 6y ago
  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)
  - BillinghamJ 6y ago
    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-limits/ 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.
    - confluence_perf 6y ago
      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)
launderthis 6y ago
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.
- BillinghamJ 6y ago
  You've shown poor understanding here. > Getting things below 1s is nearing the speed of the connection itself That is absolutely false. Internet latency is actually very low - even e.g. Paris to NZ is only about 270ms RTT, and you _do not_ need multiple full round trips to the application server for an encrypted connection - on the modern internet, connections are held open, and initial TLS termination is done at local PoPs. For services like this - as they are sharded with customer tenancy - are usually located at least in the same vague area as the customer (e.g. within North America, Western Europe, APAC etc). For most users of things like Atlassian products, that typically results in a base networking latency of <30ms, often even <10ms in good conditions. Really well engineered products can even operate in multiple regions at once - offering that sort of latency globally. > Im pretty sure he doesnt because if he could he would go there Yeah, we don't use any Atlassian products - partly for this reason. We use many Atlassian-comparable tools which have the featureset we want and which are drastically faster. > when you dont even have the response time to move your mouse and click on the next item in .5s. There is clear documented understanding of how UX is affected by with various levels of latency - https://www.nngroup.com/articles/response-times-3-important-limits/ https://www.nngroup.com/articles/response-times-3-important-... > Sometimes techies just love to argue Not really, I have no particular investment in this - I don't use any Atlassian product, nor do I plan to even if they make massive perf improvements. But I do have an objective grasp - for tools like this - of what's possible, what good looks like, and what user expectations look like. > no dont give into this guy I don't expect Atlassian is going to make any major decisions entirely based on my feedback here, but it is useful data/input for exploration, and I do feel it's right to point out that they're looking in the wrong ballpark when it comes to the scale of improvement needed.

NicoJuicy 6y ago

> A "dream world" would be more like 10ms. A gateway solely adds 50 ms. So I'm not really sure where you get your numbers/benchmarks from... They are unrealistic

BillinghamJ 6y ago
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.
- NicoJuicy 6y ago
  Lol, wasn't expecting that :p Ocelot would be a better example of an gateway https://github.com/ThreeMammals/Ocelot https://github.com/ThreeMammals/Ocelot Used for scaling up web traffic or creating bff's ( backends for frontends)
  - BillinghamJ 6y ago
    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 <0.1ms processing time (assuming no additional network calls or heavy work), and maybe 0.3ms for additional connection establishment if it hasn't been optimised to use persistent connections. 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.

fphhotchips 6y ago

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 minimum standard is unrealistic.

ZephyrBlu 6y ago
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=https%3A%2F%2Fnews.ycombinator.com%2Fuser%3Fid%3Dfphhotchips&tab=desktop https://developers.google.com/speed/pagespeed/insights/?url=...
- BillinghamJ 6y ago
  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.
Too 6y ago
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.