It's an interesting subject, I just wish his benchmarks were much more indepth.
I would like to how the amount of sequential iterations of the code, the HTTP Server, JVM, OS, kernel, latency, jitter all affect the performance.
Yes. JVMs are slow for short-lived program executions compared to native code. By default, Hotspot does not compile a method until it is executed 10K times. Most libraries in the Java ecosystem are written to optimize performance over a long execution lifespan at the possible expense of startup time. The Apache HTTP libraries allow pooling of threads, HTTP keep-alive as an implementation detail, buffer re-use, etc. So, evaluating these libraries by starting up a new JVM for each run inherently tests them under a circumstance for which they were not designed/optimized. Gradle (a build tool) sort of solves the problem of short-run invocations by forwarding command line requests to a long-running Java background daemon.
Comments
It's an interesting subject, I just wish his benchmarks were much more indepth. I would like to how the amount of sequential iterations of the code, the HTTP Server, JVM, OS, kernel, latency, jitter all affect the performance.
Yes. JVMs are slow for short-lived program executions compared to native code. By default, Hotspot does not compile a method until it is executed 10K times. Most libraries in the Java ecosystem are written to optimize performance over a long execution lifespan at the possible expense of startup time. The Apache HTTP libraries allow pooling of threads, HTTP keep-alive as an implementation detail, buffer re-use, etc. So, evaluating these libraries by starting up a new JVM for each run inherently tests them under a circumstance for which they were not designed/optimized. Gradle (a build tool) sort of solves the problem of short-run invocations by forwarding command line requests to a long-running Java background daemon.