The article talks about IO, but then benchmarks sha256. The node program doesn't work well because he's synchronously doing this:<p><pre><code> for (var i = 0; i < n; i++) { sha256(data); }
</code></pre>
He should be using crypto and the async versions. This benchmark actually is just measuring the speed of your sha256 implementation, which I would guess is equal on all 4 platforms if you actually do them correctly.
Pet peeve: tech articles/blogs which do not prominently display when the article was written. This is the single most important fact I search for before reading time sensitive tech info.<p>I can't tell when this was written, am I missing something?
I'm curious, which Java servers are creating a new Thread per request?<p>Tomcat uses acceptors threads and a request executor pool. And, if available on your platform (which it probably is), it defaults to using non-blocking IO instead of polling.<p>EDIT: It looks like he does acknowledge the executor threads are pooled. His main criticism is that "too many blocked threads are bad for a scheduler". But if Tomcat is using the NIO connector this doesn't apply, because your executor threads won't block on IO. And typically the pool size is limited to something manageable by a modern CPU (200 or so)
The ease of use chart is a joke:<p><pre><code> Java: Requires callbacks
nodejs: Requires Callbacks
</code></pre>
node has 'await', but there are other options as well than just plan callback hell.<p>Java has pretty much whatever you want. Akka, futures/promises, etc.
I visited the post fully expecting the author would benchmark the latest PHP 7.2. To my surprise, he wasn't even benchmarking 7.0, but the old 5.6. I can't take this test seriously.
The example of async I/O in Node.js is with a filesystem operation.<p>How does that work? AFAIK Linux, unlike windows, doesn't have a proper async API for filesystem I/O.<p>POSIX AIO is implemented using threads in libc and Linux AIO (io_submit, etc) only works with O_DIRECT (no kernel caching) and there are other issues depending on underlying filesystem driver.<p>Is there any solution?
While still suffering from the problem of benchmarks not reflecting real world performance, The Computer Language Benchmarks Game is an excellent resource.<p><a href="http://benchmarksgame.alioth.debian.org" rel="nofollow">http://benchmarksgame.alioth.debian.org</a>
He's using the slowest and oldest framework on Java which still is preferable to use if you want things easy to read and maintain. But if you're going for raw I/O performance and already taking the readability and maintenance challenges with the other platforms, then he really should be using Netty, Vert.x or Akka for Java.
This post seems to be from about 7 months ago. Do the 'turbofan' changes of v8/v9 make any difference to the benchmarks?<p><a href="https://www.nearform.com/blog/node-js-is-getting-a-new-v8-with-turbofan/" rel="nofollow">https://www.nearform.com/blog/node-js-is-getting-a-new-v8-wi...</a>
What a lousy article.<p>"Most Java web servers work by starting a new thread of execution for each request that comes in "<p>Nobody who has a performance critical application starts a new thread for every request.<p>That would be beyond stupid.