3 ms·

> cascading failures in cases you thought you'd properly loadtested... That's hardly unique to Java. If you crash your processes because you didn't design you

> cascading failures in cases you thought you'd properly loadtested... That's hardly unique to Java. If you crash your processes because you didn't design your application to scale to your needs, there's not much the language can do about that.

londons_explore 5y ago
It just seems easier to get yourself into a bad performance corner with Java. Other languages seem to just start slowing down as load increases. You see more variation in response times, but still plenty of throughput. Whereas Java has a sudden performance cliff that's reached, and you usually won't get it to perform well again without either removing 99% of the load or restarting the process.
- smallerfish 5y ago
  I assume you've run profilers against it and captured CPU/memory snapshots? You may be filling up the heap, leading it to get into GC cycles to try to free memory. If that's happening you either have a memory/resource leak, or you just need to allocate more heap to run your application.
- kaba0 5y ago
  > It just seems easier to get yourself into a bad performance corner with Java Well, Java’s GCs are the state of the art. If they can’t deal with the amount of garbage a program creates than nothing can. As for the rest: Which may or may not be the correct response depending on use-case. The JVM gives you the freedom to choose the approach you want. The default G1 GC for example has the target pause time setting where you can set whether you would want lower latency or higher throughput.
- deschutes 5y ago
  This is a hard problem and definitely not unique to Java. For example networks, or perhaps more appropriately, network protocols, have these kinds of cliffs as the offered load on the network increases. As I understand a particularly bad traffic jam in the early internet is what motivated congestion control in TCP. As a matter of a fact traffic is also an example of this phenomenon playing out without any (effective) compensating measures. I find "Metastable failures in distributed systems" [1] to be a really interesting and accessible exploration of the problem. [1]: https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s...

londons_explore 5y ago

It just seems easier to get yourself into a bad performance corner with Java. Other languages seem to just start slowing down as load increases. You see more variation in response times, but still plenty of throughput. Whereas Java has a sudden performance cliff that's reached, and you usually won't get it to perform well again without either removing 99% of the load or restarting the process.

smallerfish 5y ago
I assume you've run profilers against it and captured CPU/memory snapshots? You may be filling up the heap, leading it to get into GC cycles to try to free memory. If that's happening you either have a memory/resource leak, or you just need to allocate more heap to run your application.
kaba0 5y ago
> It just seems easier to get yourself into a bad performance corner with Java Well, Java’s GCs are the state of the art. If they can’t deal with the amount of garbage a program creates than nothing can. As for the rest: Which may or may not be the correct response depending on use-case. The JVM gives you the freedom to choose the approach you want. The default G1 GC for example has the target pause time setting where you can set whether you would want lower latency or higher throughput.
deschutes 5y ago
This is a hard problem and definitely not unique to Java. For example networks, or perhaps more appropriately, network protocols, have these kinds of cliffs as the offered load on the network increases. As I understand a particularly bad traffic jam in the early internet is what motivated congestion control in TCP. As a matter of a fact traffic is also an example of this phenomenon playing out without any (effective) compensating measures. I find "Metastable failures in distributed systems" [1] to be a really interesting and accessible exploration of the problem. [1]: https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s11-bronson.pdf https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s...