for (var i = 0; i < n; i++) { sha256(data); }
I can't tell when this was written, am I missing something?
Looks like it was published 6 months ago - 'Thu, 11 May 2017 09:14:20 -0400' to be precise.
Source: The /rss feed for the blog, which shows the following for this post.
<item>
<title>Server-side I/O Performance: Node vs. PHP vs. Java vs. Go</title>
<description>Understanding the Input/Output (I/O) model of your application can mean the difference between an application that deals with the load it is subjected to, and one that crumples in the face of real-world uses cases. Perhaps while your application is small and does not serve high loads, it may matter far less. But as your application’s traffic load increases, working with the wrong I/O model can get you into a world of hurt.</description>
<pubDate>Thu, 11 May 2017 09:14:20 -0400</pubDate>
<link>https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go</link>
<guid isPermaLink="false">server-side-io-performance-node-php-java-go</guid>
<dc:creator>BRAD PEABODY, DEVELOPER @ TOPTAL</dc:creator>
<media:content url="https://uploads.toptal.io/blog/post_image/120386/02-facebook-1200x627-494cb5ae75d16fa39251cb8b7d6ae877.jpg" medium="image"/>
</item>
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)
A more comprehensive benchmark is done here. https://www.techempower.com/benchmarks/#section=data-r14&hw=...
The author used a query along the lines of:
SELECT * FROM table ORDER BY RAND() LIMIT 1
SELECT * FROM table WHERE id = RAND()
Java: Requires callbacks
nodejs: Requires Callbacks
Java has pretty much whatever you want. Akka, futures/promises, etc.
Yes, it shows...
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?
> The libuv filesystem operations are different from socket operations. Socket operations use the non-blocking operations provided by the operating system. Filesystem operations use blocking functions internally, but invoke these functions in a thread pool and notify watchers registered with the event loop when application interaction is required.
Can you show that is true?
https://www.nearform.com/blog/node-js-is-getting-a-new-v8-wi...
"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.
It is the only thing that matters line for line.
It's likely that C or Rust or C++ would be much faster than Java or Go since they have large runtime overheads; it turns out having a runtime and how heavy it is matter too, not just if it's compiled.
There are also cases where non-compiled languages can beat out compiled ones. For example, lua with LuaJIT is incredibly fast, and beats out compiled languages with heavy runtimes (like java/C#) in quite a few microbenchmarks.
Java has a specification and has lots of implementations.
The majority of commercial implementations of Java have native code compilers, and Oracle is in the process of improving the AOT compiler introduced in Java 9.
When the operation is finished, then they become runnable again so the kernel scheduler runs them--that is, it runs the code that comes after the I/O operation.
This code (from libuv) notifies the requester that the operation is complete.
1) The main event loop thread.
2) a thread pool of "workers" which make the actual I/O request and sleep while waiting for the I/O. Then when a "worker" thread is set to runnable again by the kernel(because it's I/O request has been completed)notifies the main event loop thread via a signal?
Is that correct?