Hacker News Reader

Comment by dboreham | Hacker News Reader

Sometimes matters, e.g. when you deploy new code.

Not really, just do a rolling deployment like you should be doing anyway. No one cares if the new version takes 1 millisecond to start up or 3 seconds because they literally won't notice.

Rolling deployment is a hack imho. Adds complexity and hence yet more potential failure modes.

Hardly, it's a fantastic guardrail when combined with health checks. You can say "you don't need it", but everyone makes mistakes sometimes. Make those mistakes not matter. You also take backups, right? Same idea.

It has a non-zero cost though, which is why I don't like it. Things go wrong with the "roll" for example. You have potentially two versions of your code running against the same DB for some time.

Stop -> deploy code -> start is simpler and less likely to go wrong.

But 3 seconds isn't on the table. It is more like 20-30 seconds on a medium sized app and 8 seconds for a small one.

If your Java app takes half a minute to initialise it's the app's problem, not Java. Modern Java frameworks have moved from a dynamic deployment model to statically compiled and can start in milliseconds. (for example, see the benchmarks on https://quarkus.io/blog/runtime-performance/)

How would real-world JVM startup times matter in deployments?

You exec a process expecting it to begin operating, providing some networked service, in a reasonable time. Instead it doesn't do that. It spends tens of seconds, sometimes minutes, running JIT and other sundry startup overhead.

You may not have seen this if you haven't used Scala...

Yeah, Scala is absurdly bad for startup time because of poor modularization of the standard library. It's a decent language with a terrible standard library.

Genuinely curious, what kind of application are you running? Which JVM are you using? Are you aggressively GC tuning? Very low on memory? I've used Scala from 2.8 up to 3.0, for microservice systems, monoliths, data pipelines, machine learning (way back), desktop apps for research using Swing, an Android app (worst idea ever), highly imperative to very functional, and I don't think I've ever seen anything remotely as bad as that even on genuinely big codebases. Hundreds of ms, sure, but minutes just getting the JVM up and running? I can see how that would be problematic.

Ok, so to expand: applications that I've been responsible for from the beginning have not had long start up times. Where I've seen it is with other folks applications where I was hired as a consultant to look at performance.

The most recent example was a Scala monolith. It had to use JVM 1.8 because <reasons> prevented migration to 11 (tried quite hard, but never succeeded). GC tuning doesn't really apply when considering start up delay, but yes it had been tuned over the years. Memory was not limited. The application, mainly due to Scala, had tens of thousands of classes. They all seemed to get JIT'ed on start up, which was the primary reason for the slow start up. People involved (who had come from heavy Scala shops like Twitter) seemed to think it was normal.

You reboot and suddenly your CPU is at 100% for 20 minutes starting every web service...

If your CPU is at 100% for 20 minutes starting every web service, that is definitely your problem, not Java’s problem.

JVM startup times make using it in Lambda or scaling container clusters awkward. Scaling can't happen fast enough for traffic spikes when the startup time and cold start performance is crap.

Reply on news.ycombinator.com