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.
I can't tell when this was written, am I missing something?
I was reading the article until a giant fullscreen ad popped up and I had to close the tab. Sorry, no thanks.
I'm curious, which Java servers are creating a new Thread per request?
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.
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)
So he acknowledges that has not benchmarked the best options for Java and then selects Go as a winner, what a joke.
The ease of use chart is a joke:
Java: Requires callbacks
nodejs: Requires Callbacks
node has 'await', but there are other options as well than just plan callback hell.Java has pretty much whatever you want. Akka, futures/promises, etc.
>Before I get into the section for Go, it’s appropriate for me to disclose that I am a Go fanboy
Yes, it shows...
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.
PHP 5.6.x and old version of Node too - this article is too old to be of serious use.
The example of async I/O in Node.js is with a filesystem operation.
How does that work? AFAIK Linux, unlike windows, doesn't have a proper async API for filesystem I/O.
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.
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.
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?
https://www.nearform.com/blog/node-js-is-getting-a-new-v8-wi...
What a lousy article.
"Most Java web servers work by starting a new thread of execution for each request that comes in "
Nobody who has a performance critical application starts a new thread for every request.
That would be beyond stupid.
He’s using Apache in prefork mode with mod_php, which is a little bit 10 years ago. Worker or Event with php-fpm is standard now.
Only Java can share memory between threads.
Line for line Go will be faster it is compiled.
It is the only thing that matters line for line.
The article talks about IO, but then benchmarks sha256. The node program doesn't work well because he's synchronously doing this:
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.