6 ms·

We have certainly heard from some customers that agree that 'everything' is slow, but we've also heard from other customers saying they have no problems. We wo

We have certainly heard from some customers that agree that 'everything' is slow, but we've also heard from other customers saying they have no problems. We would love to fix "everything", and we have some longer term projects focused on this -> However, "everything" fixes seem to be a more incremental boost and also take longer time to complete. If you have any feedback about "specific" items that are the most frustrating, we'd love to hear about those -> targeted fixes for specific can be much faster, much greater gains, and usually offer better user experience gain/engineering time returns. If not, I can only say that we are definitely working on making 'everything faster' (edit: trying to reply but looks like HN is limiting my reply rate) (edit: maybe I can post my replies here and hopefully they'll get read) ------ @rusticpenn - This is definitely possible that 'some users are just used to it'. But we also see a very wide variance in individual customers' performance numbers (ie. some instances have consistently faster performance than other instances), and even within individual instances variance amongst users (some users have consistently faster experience than other users on the same instance) -> we're trying what we can to narrow down the causes in this variance. Hearing from "users with slow experiences" is simply one of the ways we're trying to track this down, but it helps if users are willing to provide more info. -------- @ratww - thank you for the suggestion! We have some amount of data that helps us see what might be different between instances, but haven't gone out of our way to 'interview a fast customer', I'll bring this up with the team to see. The two biggest factors I think we've seen: slow machines can contribute (but not a necessity), and large pages (especially with large tables, or large number of tables) can contribute.

rusticpenn 6y ago
> but we've also heard from other customers saying they have no problems I am sorry, there are probably customers who are used to the tools. Maybe they don't pass the Mom test. That point comes out as unnecessary defense here.
- dylan604 6y ago
  I think these maybe the same people calling Trump to say that he's a great president. Both claims are equally as unbelievable.
ratww 6y ago
> but we've also heard from other customers saying they have no problems Can I suggest following up with those customers to see if and how they're using the product, what's their computer configuration, if there's anything special about them?
- mgkimsal 6y ago
  There's a bit of verbal sleight-of-hand going on - probably not intentionally. "This is very slow" "We have no problems" These aren't addressing the same things, really (unless the OP was translating "we're happy with the speed of the entire system" as "we have no problems"). Are the people reporting "no problems" actual end users. People I know who've become acclimated to Jira that I know would happily respond "we have no problems" while the people below them who have to use Jira 10x more often (multiple times per hour, vs a daily look at progress, for example) would happily say "this is slow as molasses (and that's a problem)".
acdha 6y ago
> We have certainly heard from some customers that agree that 'everything' is slow, but we've also heard from other customers saying they have no problems. What do your metrics show? I instrument my web sites so I know how long every operation – server responses, front-end JS changes, etc. – takes and can guide my development accordingly. You have a much larger budget and could be answering this question with hard data. I’ll second the “everything” responses. Request Tracker on 1990s hardware was considerably faster than Jira is today - and better for serious use, too.
- confluence_perf 6y ago
  Hi acdha, We have metrics, but of course as with many such things you always want more insights than the amount of data you're collecting (so we're always trying to grow this as appropriate). This data is what led to the above (added edit trying to reply to @rusticpenn) saying we can see that "some instances are slower than others", and "some users are slower than others". I can't share those numbers of course though. However, privacy reasons does prevent us from collecting too much data, so differentiating why individual users might have different experiences (even when other known factors are similar/identical) is difficult. Also I'd be happy to take any suggestions you have about what to look at back to my engineering team, if you're willing to share other ideas. I know we're tracking several of the ones you mention but more options is always better.
  - acdha 6y ago
    I mean, it really is everything. If it were my project I’d make sure I have telemetry on all UI actions and would then set a threshold (say 200ms), triage everything which has a percentile consistently over that threshold to look for easy fixes, and then set a policy that each release only improves on those numbers. I can’t think of any user-visible changes to Jira or Confluence in the last 5 years which I wouldn’t trade in a heartbeat for good performance.
    - confluence_perf 6y ago
      Hi acdha, Thank you for the advice - how about on the page load side? Our biggest problem is probably the variance issue (mentioned in other subthreads) -> we can't easily tell what is the difference between a slow and a fast load in many cases. Even if we compare things that are available from the metrics like CPU, Mem, and Network speed, those are not very granular metrics (for example, to understand someone with 16 threads was actually at 95% Mem used during that page load), and have little correlation at a wide level with page load speed.
andrewflnr 6y ago
Jira obviously has systemic performance problems that a few users have fast enough computers or networks to push through. There will be no shortcut to "targeted fixes" for "greater gains". Persistently asking for particular workflows, as you've been doing throughout this thread, shows a failure to understand the scope of the problem. In fact it makes me wonder if your paycheck depends on not understanding it. It sure seems like someone's does.

rusticpenn 6y ago

> but we've also heard from other customers saying they have no problems I am sorry, there are probably customers who are used to the tools. Maybe they don't pass the Mom test. That point comes out as unnecessary defense here.

dylan604 6y ago
I think these maybe the same people calling Trump to say that he's a great president. Both claims are equally as unbelievable.

ratww 6y ago

> but we've also heard from other customers saying they have no problems Can I suggest following up with those customers to see if and how they're using the product, what's their computer configuration, if there's anything special about them?

mgkimsal 6y ago
There's a bit of verbal sleight-of-hand going on - probably not intentionally. "This is very slow" "We have no problems" These aren't addressing the same things, really (unless the OP was translating "we're happy with the speed of the entire system" as "we have no problems"). Are the people reporting "no problems" actual end users. People I know who've become acclimated to Jira that I know would happily respond "we have no problems" while the people below them who have to use Jira 10x more often (multiple times per hour, vs a daily look at progress, for example) would happily say "this is slow as molasses (and that's a problem)".

acdha 6y ago

> We have certainly heard from some customers that agree that 'everything' is slow, but we've also heard from other customers saying they have no problems. What do your metrics show? I instrument my web sites so I know how long every operation – server responses, front-end JS changes, etc. – takes and can guide my development accordingly. You have a much larger budget and could be answering this question with hard data. I’ll second the “everything” responses. Request Tracker on 1990s hardware was considerably faster than Jira is today - and better for serious use, too.

confluence_perf 6y ago
Hi acdha, We have metrics, but of course as with many such things you always want more insights than the amount of data you're collecting (so we're always trying to grow this as appropriate). This data is what led to the above (added edit trying to reply to @rusticpenn) saying we can see that "some instances are slower than others", and "some users are slower than others". I can't share those numbers of course though. However, privacy reasons does prevent us from collecting too much data, so differentiating why individual users might have different experiences (even when other known factors are similar/identical) is difficult. Also I'd be happy to take any suggestions you have about what to look at back to my engineering team, if you're willing to share other ideas. I know we're tracking several of the ones you mention but more options is always better.
- acdha 6y ago
  I mean, it really is everything. If it were my project I’d make sure I have telemetry on all UI actions and would then set a threshold (say 200ms), triage everything which has a percentile consistently over that threshold to look for easy fixes, and then set a policy that each release only improves on those numbers. I can’t think of any user-visible changes to Jira or Confluence in the last 5 years which I wouldn’t trade in a heartbeat for good performance.
  - confluence_perf 6y ago
    Hi acdha, Thank you for the advice - how about on the page load side? Our biggest problem is probably the variance issue (mentioned in other subthreads) -> we can't easily tell what is the difference between a slow and a fast load in many cases. Even if we compare things that are available from the metrics like CPU, Mem, and Network speed, those are not very granular metrics (for example, to understand someone with 16 threads was actually at 95% Mem used during that page load), and have little correlation at a wide level with page load speed.

andrewflnr 6y ago

Jira obviously has systemic performance problems that a few users have fast enough computers or networks to push through. There will be no shortcut to "targeted fixes" for "greater gains". Persistently asking for particular workflows, as you've been doing throughout this thread, shows a failure to understand the scope of the problem. In fact it makes me wonder if your paycheck depends on not understanding it. It sure seems like someone's does.