[confluence_perf]

Best I can say here (as a Confluence PM not a Jira one, and in a public forum) is that customers are not the only ones that experience this pain, and the appropriate folks are notified on a regular basis.

I think the genesis of this is historically many different editable fields might had different modules behind them (not every single one a different one, but maybe a handful of common ones). It looks like for whatever reason we (Atlassian) haven't fully migrated all of them to the newest common editor modules -> I don't know anything for sure though

[acdha]

I’d bet on legacy code which nobody wants to touch and we’ve all been there. I’d recommend having an option to add a Markdown flag which can be enabled for all new records, leaving the old stuff alone, since this usually comes up in the context of people using GitLab instead because it’s so, so much better for technical work. Once Jira is just links to Gitlab, people start asking what justifies the hefty cost for a tool the team doesn’t use.

[t-writescode]

This is the top response on your profile, so I’m commenting here.

Atlassian is developed and run in Australia, right?

Have you tried running your website and doing the things we mention here from a VPN that goes through the United States or Europe to experience our latency to your servers overall?

I haven’t done any testing myself on this, but if you’re doing serial requests and each request is an https call back and forth to Australia, that’s easily 200ms every request, even if total server time is milliseconds.

And even if you support parallel, if you limit the number of requests per non-whitelisted IP by a lot, it can very easily become approximately serial

[confluence_perf]

Hi t-writescode,

For the most part, each individual top line products' team operates out of a different site, with Confluence operating in Silicon Valley (mostly). I assume this is public information (or derivable) so I think it's safe to share.

Internally we have a few Confluence Cloud instances we use, with a single main one shared by the entire company (basically) which is located in a single area (somewhere?), though the VPN connection points are different.

So from a network topology standpoint our experience shouldn't be too different from most customers (at a very gross level) -> summary is, we definitely have users representative of 'bad networking', but you're right maybe I should be trying to intentionally degrade mine (right now i think its two cross US hops, but could be wrong).

I'll make sure our team looks at this dimension -> I don't think it's possible within our telemetry data, but maybe simulating it will get some interesting results.

I do recall reading once about something about AWS infrastructure (endpoints? edges?) having some configuration that causes omething like this: 1 - first returned packet is some some small size 2 - next packet (after ack is returned) can be double the size 3 - same 4 - same 5 - until max packet size

And though (1) is configurable (in theory), and I think the doubling/size increase is configurable (in theory), AWS does not allow for this configuration in their services.

But I can't find what I was reading so if anyone knows about that (a) being a problem and (b) how to work around it, let me know!