4 ms·

Even if the microservices platform is running at 1% capacity, it's guaranteed to have worse performance than almost any monolith architecture. It's very rare t

Even if the microservices platform is running at 1% capacity, it's guaranteed to have worse performance than almost any monolith architecture. It's very rare to meet a developer who has even the vaguest notion of what an RPC call costs in terms of microseconds. Fewer still that know about issues such as head-of-line blocking, the effects of load balancer modes such as hash versus round-robin, or the CPU overheads of protocol ser/des. If you have an architecture that involves about 5 hops combined with sidecars, envoys, reverse proxies, and multiple zones you're almost certainly spending 99% to 99.9% of the wall clock time just waiting. The useful compute time can rapidly start to approach zero. This is how you end up with apps like Jira taking a solid minute to show an empty form.

throwaway48540 2y ago
Are you talking about cloud Jira? I use it daily and it's very quick, even search results appear immediately...
- nikau 2y ago
  Have you ever used an old ticketing system like remedy? Ugly as sin, but screens appear instantly. I think Web apps have been around so long now people have forgotten how unresponsive things are vs old 2 tier stuff.
  - BeefWellington 2y ago
    There's a definite vibe these days of "this is how it's always been" when it really hasn't.
  - throwaway48540 2y ago
    The SPA Jira cloud is faster than anything server rendered for me, my connection is shit. In Jira I can at least move to static forms quickly and I'm not downloading the entire page on every move.
  - chuckadams 2y ago
    I’ve used Remedy in three different shops, and the experience varied dramatically. The entry screen might have popped instantly, but RPC timeouts on submission were common. Tab order for controls was the order they were added, not position on the screen. Remedy could be pleasant, but it was very dependent on a competent admin to set up and maintain it.
- abrookewood 2y ago
  Maybe you're being honest, but you're using a throwaway account and I use Cloud Jira every day. It's slow and bloated and drives me crazy.
  - kahmeal 2y ago
    Has a LOT to do with how it's configured and what plugins are installed.
    - jiggawatts 2y ago
      It really doesn't. This is the excuse trotted out by Atlassian staff when defending their products in public forums, essentially "corporate propaganda". They have a history of gaslighting users, either telling them to disregard the evidence of their own lying eyes, or that it's their own fault for using the product wrong somehow. I tested the Jira cloud service with a new, blank account. Zero data, zero customisations, zero security rules. Empty. Almost all basic operations took tens of seconds to run, even when run repeatedly to warm up any internal caches. Opening a new issue ticket form was especially bad, taking nearly a minute. Other Atlassian excuses included: corporate web proxy servers (I have none), slow Internet (gigabit fibre), slow PCs (gaming laptop on "high performance" settings), browser security plugins (none), etc...
      - ffsm8 2y ago
        > Opening a new issue ticket form was especially bad, taking nearly a minute. At that point, something mustve been wrong with your instance. I'd never call jira fast, but the new ticked dialog on a unconfigured instance opens within <10s (which is absolutely horrendous performance to be clear. Anything more then 200-500ms is.)
        jiggawatts 2y ago
        Cloud Jira is notably slower than on-prem Jira, which takes on the order of 10 seconds like you said.
- lmm 2y ago
  With cloud Jira you get thrown on a shared instance with no control over who you're sharing with, so it's random whether yours will be fast or extremely slow.
- Lucasoato 2y ago
  I’m starting to think that these people praising Jira are just part of an architected PR campaign that tries to deny what’s evident to the end users: Jira is slow, bloated in many cases almost unusable.
deleted 2y ago
[deleted]
randomdata 2y ago
> It's very rare to meet a developer who has even the vaguest notion of what an RPC call costs in terms of microseconds. To be fair, small time units are difficult to internalize. Just look at what happens when someone finds out that it takes tens of nanoseconds to call a C function in Go (gc). They regularly conclude that it's completely unusable, and not just in a tight loop with an unfathomable number of calls, but even for a single call in their program that runs once per day. You can flat out tell another developer exactly how many microseconds the RPC is going to add and they still aren't apt to get it. It is not rare to find developers who understand that RPC has a higher cost than a local function, though, and with enough understanding of that to know that there could be a problem if overused. Where they often fall down, however, is when the tools and frameworks try to hide the complexity by making RPC look like a local function. It then becomes easy to miss that there is additional overheard to consider. Make the complexity explicit and you won't find many developers oblivious to it.
- j16sdiz 2y ago
  Those time cost need to contextualize with time budgets for each service. Without that, it is always somebody else's problem in a RPC world.
- HideousKojima 2y ago
  >Just look at what happens when someone finds out that it takes tens of nanoseconds to call a C function in Go (gc). I'm not too familiar with Go but my default assumption is that it's just used as a convenient excuse to avoid learning how to do FFI.
lmm 2y ago
> This is how you end up with apps like Jira taking a solid minute to show an empty form. Nah. Jira was horrible and slow long before the microservice trend.
- p_l 2y ago
  JIRA slowness usually involved under provisioned server resources in my experience
  - lmm 2y ago
    Nope. You could put it on a beefy machine with a beefy database and it would still crawl a lot of the time. It just had some combination of terrible database querying and general slowness. The whole generic inner-platform effect way it's constructed (e.g. having its own ticket query language that they presumably translate generically into SQL) was probably a big factor.
    - p_l 2y ago
      Not discounting your knowledge, but somehow that was never the case for me across multiple companies, with I think one exception and even that one wasn't as slow as people talk about, despite being the worst I ever encountered. In fact, I'd argue that one of the biggest annoyances I had in last job was that I actually missed JIRA, or rather it's glorious issue list view with its keyboard shortcuts.
otabdeveloper4 2y ago
It's actually worse than what you said. In 2024 the network is the only resource we can't upgrade on demand. There are physical limits we can't change. (I.e., there are only so many wires connecting your machines, and any significant upgrade involves building your own data center.) So really eventually we'll all be optimizing around network interfaces as the bottleneck.
- jiggawatts 2y ago
  cough speed of light cough

throwaway48540 2y ago

Are you talking about cloud Jira? I use it daily and it's very quick, even search results appear immediately...

nikau 2y ago
Have you ever used an old ticketing system like remedy? Ugly as sin, but screens appear instantly. I think Web apps have been around so long now people have forgotten how unresponsive things are vs old 2 tier stuff.
- BeefWellington 2y ago
  There's a definite vibe these days of "this is how it's always been" when it really hasn't.
- throwaway48540 2y ago
  The SPA Jira cloud is faster than anything server rendered for me, my connection is shit. In Jira I can at least move to static forms quickly and I'm not downloading the entire page on every move.
- chuckadams 2y ago
  I’ve used Remedy in three different shops, and the experience varied dramatically. The entry screen might have popped instantly, but RPC timeouts on submission were common. Tab order for controls was the order they were added, not position on the screen. Remedy could be pleasant, but it was very dependent on a competent admin to set up and maintain it.
abrookewood 2y ago
Maybe you're being honest, but you're using a throwaway account and I use Cloud Jira every day. It's slow and bloated and drives me crazy.
- kahmeal 2y ago
  Has a LOT to do with how it's configured and what plugins are installed.
  - jiggawatts 2y ago
    It really doesn't. This is the excuse trotted out by Atlassian staff when defending their products in public forums, essentially "corporate propaganda". They have a history of gaslighting users, either telling them to disregard the evidence of their own lying eyes, or that it's their own fault for using the product wrong somehow. I tested the Jira cloud service with a new, blank account. Zero data, zero customisations, zero security rules. Empty. Almost all basic operations took tens of seconds to run, even when run repeatedly to warm up any internal caches. Opening a new issue ticket form was especially bad, taking nearly a minute. Other Atlassian excuses included: corporate web proxy servers (I have none), slow Internet (gigabit fibre), slow PCs (gaming laptop on "high performance" settings), browser security plugins (none), etc...
    - ffsm8 2y ago
      > Opening a new issue ticket form was especially bad, taking nearly a minute. At that point, something mustve been wrong with your instance. I'd never call jira fast, but the new ticked dialog on a unconfigured instance opens within <10s (which is absolutely horrendous performance to be clear. Anything more then 200-500ms is.)
      - jiggawatts 2y ago
        Cloud Jira is notably slower than on-prem Jira, which takes on the order of 10 seconds like you said.
lmm 2y ago
With cloud Jira you get thrown on a shared instance with no control over who you're sharing with, so it's random whether yours will be fast or extremely slow.
Lucasoato 2y ago
I’m starting to think that these people praising Jira are just part of an architected PR campaign that tries to deny what’s evident to the end users: Jira is slow, bloated in many cases almost unusable.

deleted 2y ago

[deleted]

randomdata 2y ago

> It's very rare to meet a developer who has even the vaguest notion of what an RPC call costs in terms of microseconds. To be fair, small time units are difficult to internalize. Just look at what happens when someone finds out that it takes tens of nanoseconds to call a C function in Go (gc). They regularly conclude that it's completely unusable, and not just in a tight loop with an unfathomable number of calls, but even for a single call in their program that runs once per day. You can flat out tell another developer exactly how many microseconds the RPC is going to add and they still aren't apt to get it. It is not rare to find developers who understand that RPC has a higher cost than a local function, though, and with enough understanding of that to know that there could be a problem if overused. Where they often fall down, however, is when the tools and frameworks try to hide the complexity by making RPC look like a local function. It then becomes easy to miss that there is additional overheard to consider. Make the complexity explicit and you won't find many developers oblivious to it.

j16sdiz 2y ago
Those time cost need to contextualize with time budgets for each service. Without that, it is always somebody else's problem in a RPC world.
HideousKojima 2y ago
>Just look at what happens when someone finds out that it takes tens of nanoseconds to call a C function in Go (gc). I'm not too familiar with Go but my default assumption is that it's just used as a convenient excuse to avoid learning how to do FFI.

lmm 2y ago

> This is how you end up with apps like Jira taking a solid minute to show an empty form. Nah. Jira was horrible and slow long before the microservice trend.

p_l 2y ago
JIRA slowness usually involved under provisioned server resources in my experience
- lmm 2y ago
  Nope. You could put it on a beefy machine with a beefy database and it would still crawl a lot of the time. It just had some combination of terrible database querying and general slowness. The whole generic inner-platform effect way it's constructed (e.g. having its own ticket query language that they presumably translate generically into SQL) was probably a big factor.
  - p_l 2y ago
    Not discounting your knowledge, but somehow that was never the case for me across multiple companies, with I think one exception and even that one wasn't as slow as people talk about, despite being the worst I ever encountered. In fact, I'd argue that one of the biggest annoyances I had in last job was that I actually missed JIRA, or rather it's glorious issue list view with its keyboard shortcuts.

otabdeveloper4 2y ago

It's actually worse than what you said. In 2024 the network is the only resource we can't upgrade on demand. There are physical limits we can't change. (I.e., there are only so many wires connecting your machines, and any significant upgrade involves building your own data center.) So really eventually we'll all be optimizing around network interfaces as the bottleneck.

jiggawatts 2y ago
cough speed of light cough