7 ms·

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 detail

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, everything would load in < 1s (everything drawn, everything interactive), but working our way down to that will take time. We're currently looking at each use case to understand the '(a) paint faster vs (b) interactive faster' tradeoff and trying to decide which cases the user has a better experience with (a) or (b). In Confluence this is clearer in some places than in others, but in Jira it's less clear I think (I work on Confluence, I probably shouldn't speak for Jira specifics). It always comes down to a limitation of resources though, which is why we're always hoping to get as specific feedback as possible.

BillinghamJ 6y ago
> 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.
- 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.
orangecat 6y ago
Hopefully this demonstrates that the anti-performance-discussion ToS clause is harmful not only to your customers but to you as well. You're getting useful information here only because some people are willing to openly violate it.
- Judgmentality 6y ago
  Not to mention the reputational damage from people asking "why the hell is this in the contract in the first place?" It says they're so afraid of the quality of their product they'd rather litigate their customers than fix their product.
  - dane-pgp 6y ago
    I wonder if these should be called "Streisand clauses", because it seems that the net effect will be for people to increasingly associate Atlassian with badly performing software. Certainly if someone asked me what I know about Atlassian, this would now be one of the first things that come to mind.
    - texasbigdata 6y ago
      At the margin some one reading this thread is much more likely to hop of Atlassian and short the stock than than they are to become a new user with one of those shiny high net promoter scores and “land and expand” wallet shares they brag about in their investor relations materials.
jabberwcky 6y ago
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 < 1s (everything drawn, everything interactive), 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 delivered this software is antithetical to anything I look for in a software project I want to use or contribute to. How can I possibly do my job to any degree of satisfaction when I'm tracking work in a tool that requires 15 seconds between mouse clicks? That is the reality of Jira, and as a result I refuse to use it, or work for people who find that acceptable, because it's a "broken window" that tells me much more about the target environment than merely something about suboptimal bug trackers. Your page budget should be 100ms max, given all your tools actually do are track a couple of text fields in a pleasing style. Whoever the architecture astronauts are at Atlassian that created the current mess, flush them out, no seat is too senior -- this is an existential issue for your business.
- BillinghamJ 6y ago
  > 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!
- cyberpunk 6y ago
  Hmmm. I mean. I'm a contractor too, and I share your pain, but ... I'm really impressed you walk out of paid work because of the issue tracker your client uses.. It sounds a bit like they dodged a bigger bullet than you did tbh mate. All these systems suck. You learn to live with them, for me I do this: Everything goes in OmniFocus, I have a keyboard shortcut to create a task that takes <1sec, hit enter twice and it's stored. Twice a day I go though all the tasks I entered this way, and I either mark them done or assign them to various projects/tags/labels I have setup on OmniFocus. 15 mins before I finish work for the day at a client, I update whatever ticket system they use (mostly Jira, but also sometimes even worse things like servicenow) and also whatever enterprise crapware my agency uses (usually some sap based bollocks). The last 15 mins suck. But it's part of the deal. I can't imagine how strongly you feel to turn down contractor rates due to a ticket system.. I mean, come on? Edit: Also - btw -- if you're on a Mac the app-store 'fat-app' version of Jira is about 10x better than using the web interface, I suggest you give it a try.
jerf 6y ago
"'(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 total takes but also all the other times. You will learn a lot if you haven't done this yet. It will be much more informative than anything we can tell you. Second, once an issue is loaded, right click on almost anything in the page (description, title, whatever) and select "Inspect Element". Look at how many layers deep you are in the HTML. I also find it useful to Save the Web Page (Complete) once it's all done rendering, then load it from disk with the network tab loaded in the debugger. It can give a quick & dirty read on how much time it takes just to render the page, separate from all network and server-side code issues. I have a bit of a pet theory that a lot of modern slowdown on the web is simply how much of the web is literally dozens and dozens of DOM layers deep in containers that are all technically resizeable (even though it is always going to have one element in it, or could be fixed in some other simple way), so the browser layout engine is stressed to the limit because of all the nested O(n) & O(n log n) stuff going on. (It must not be a true O(n^2) because our pages would never load at all, but even the well-optimized browser engines can just be drowned in nodes.) I don't have enough front-end experience to be sure, but both times I took a static snapshot of a page for some local UI I had access to that was straight-up 2+ seconds to render from disk, I was able to go in and just start slicing away at the tags to get a page that was virtually identical (not quite, but close enough) that rendered in a small fraction of a second, just with HTML changes. My guess is that fixing the network issues will be a nightmare, because the 5 Whys analysis probably lands you at Conway's Law around #4 or #5. But, assuming you also have a client-side rendering issue (I don't use JIRA Cloud (yet) but I can vouch that the server product does), you may be able to get some traction just by peeling away an engineer to take a snapshot of the page and see what it takes to produce a page that looks (nearly) identical but renders more quickly. That will not itself be a "solution" but it'll probably provide a lot of insight. [1]: https://news.ycombinator.com/item?id=22889975 https://news.ycombinator.com/item?id=22889975
- confluence_perf 6y ago
magicalhippo 6y ago
> In a dream world of course, everything would load in < 1s (everything drawn, everything interactive), but working our way down to that will take time. FWIW our on-prem install uses <1s for opening issues, running a search etc. Too bad that's a dream world you've decided should no longer be...
- samb1729 6y ago
  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 there’s no amount of hardware or bandwidth a client can throw at the problem to fix it.
  - magicalhippo 6y ago
    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.
    - samb1729 6y ago
      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.

BillinghamJ 6y ago

> 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.
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.

orangecat 6y ago

Hopefully this demonstrates that the anti-performance-discussion ToS clause is harmful not only to your customers but to you as well. You're getting useful information here only because some people are willing to openly violate it.

Judgmentality 6y ago
Not to mention the reputational damage from people asking "why the hell is this in the contract in the first place?" It says they're so afraid of the quality of their product they'd rather litigate their customers than fix their product.
- dane-pgp 6y ago
  I wonder if these should be called "Streisand clauses", because it seems that the net effect will be for people to increasingly associate Atlassian with badly performing software. Certainly if someone asked me what I know about Atlassian, this would now be one of the first things that come to mind.
  - texasbigdata 6y ago
    At the margin some one reading this thread is much more likely to hop of Atlassian and short the stock than than they are to become a new user with one of those shiny high net promoter scores and “land and expand” wallet shares they brag about in their investor relations materials.

jabberwcky 6y ago

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 < 1s (everything drawn, everything interactive), 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 delivered this software is antithetical to anything I look for in a software project I want to use or contribute to. How can I possibly do my job to any degree of satisfaction when I'm tracking work in a tool that requires 15 seconds between mouse clicks? That is the reality of Jira, and as a result I refuse to use it, or work for people who find that acceptable, because it's a "broken window" that tells me much more about the target environment than merely something about suboptimal bug trackers. Your page budget should be 100ms max, given all your tools actually do are track a couple of text fields in a pleasing style. Whoever the architecture astronauts are at Atlassian that created the current mess, flush them out, no seat is too senior -- this is an existential issue for your business.

BillinghamJ 6y ago
> 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!
cyberpunk 6y ago
Hmmm. I mean. I'm a contractor too, and I share your pain, but ... I'm really impressed you walk out of paid work because of the issue tracker your client uses.. It sounds a bit like they dodged a bigger bullet than you did tbh mate. All these systems suck. You learn to live with them, for me I do this: Everything goes in OmniFocus, I have a keyboard shortcut to create a task that takes <1sec, hit enter twice and it's stored. Twice a day I go though all the tasks I entered this way, and I either mark them done or assign them to various projects/tags/labels I have setup on OmniFocus. 15 mins before I finish work for the day at a client, I update whatever ticket system they use (mostly Jira, but also sometimes even worse things like servicenow) and also whatever enterprise crapware my agency uses (usually some sap based bollocks). The last 15 mins suck. But it's part of the deal. I can't imagine how strongly you feel to turn down contractor rates due to a ticket system.. I mean, come on? Edit: Also - btw -- if you're on a Mac the app-store 'fat-app' version of Jira is about 10x better than using the web interface, I suggest you give it a try.

jerf 6y ago

"'(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 total takes but also all the other times. You will learn a lot if you haven't done this yet. It will be much more informative than anything we can tell you. Second, once an issue is loaded, right click on almost anything in the page (description, title, whatever) and select "Inspect Element". Look at how many layers deep you are in the HTML. I also find it useful to Save the Web Page (Complete) once it's all done rendering, then load it from disk with the network tab loaded in the debugger. It can give a quick & dirty read on how much time it takes just to render the page, separate from all network and server-side code issues. I have a bit of a pet theory that a lot of modern slowdown on the web is simply how much of the web is literally dozens and dozens of DOM layers deep in containers that are all technically resizeable (even though it is always going to have one element in it, or could be fixed in some other simple way), so the browser layout engine is stressed to the limit because of all the nested O(n) & O(n log n) stuff going on. (It must not be a true O(n^2) because our pages would never load at all, but even the well-optimized browser engines can just be drowned in nodes.) I don't have enough front-end experience to be sure, but both times I took a static snapshot of a page for some local UI I had access to that was straight-up 2+ seconds to render from disk, I was able to go in and just start slicing away at the tags to get a page that was virtually identical (not quite, but close enough) that rendered in a small fraction of a second, just with HTML changes. My guess is that fixing the network issues will be a nightmare, because the 5 Whys analysis probably lands you at Conway's Law around #4 or #5. But, assuming you also have a client-side rendering issue (I don't use JIRA Cloud (yet) but I can vouch that the server product does), you may be able to get some traction just by peeling away an engineer to take a snapshot of the page and see what it takes to produce a page that looks (nearly) identical but renders more quickly. That will not itself be a "solution" but it'll probably provide a lot of insight. [1]: https://news.ycombinator.com/item?id=22889975 https://news.ycombinator.com/item?id=22889975

confluence_perf 6y ago

magicalhippo 6y ago

> In a dream world of course, everything would load in < 1s (everything drawn, everything interactive), but working our way down to that will take time. FWIW our on-prem install uses <1s for opening issues, running a search etc. Too bad that's a dream world you've decided should no longer be...

samb1729 6y ago
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 there’s no amount of hardware or bandwidth a client can throw at the problem to fix it.
- magicalhippo 6y ago
  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.
  - samb1729 6y ago
    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.