Does this mean ...

No. We are going to compare Apples and Oranges here.

Node.js's non-blocking asynchronous event-driven processing model spawns new threads automatically for all kind of I/O activities (network, HDD, Block-devices, etc.). Node.js uses a stack and command-queue to manage tasks. The command-queue helps to keep the CPU and memory pressure low.

Java network libraries/frameworks typically spawn new threads programmatically per request which adds more pressure to CPU and memory management. The CPU spends more time on swapping memory code pages and switching between processes and threads, the more requests coming in.

Node.js can't gain more speed from CPUs with more CPU cores; Java benefits from more cores pretty quickly. Node.js can't access high amount of memory without tuning it's embedded V8 engine via command line parameters; Java benefits from more memory pretty quickly, it only takes some few start parameters.

A typical Node.js machine has only 2 or 4 CPU cores and something around 2GB or 4GB of RAM memory. Because you can't get more performance without further tuning and experiment with V8 parameters. Running benchmarks on the same machine for Node.js and Java lets Java look pretty silly.

And we still can't compare Node.js and Java easily. Vert.x is a project trying to enable Node.js's processing model for Java developers. Vert.x benchmark scenarios were abusing unknowingly Java build in mechanics, rendering Vert.x results much higher than Node.js's results. Java buffers files in memory if the file size is small enough. Each time accessing the file serves its content from RAM, which is much much faster than any HDD or SSD. Node.js assumes the content may change and reads the file fresh. Using the same buffer trick for Node.js renders both pretty much equal regarding speed. Bombing both with thousands of requests per second let's look Java silly again - if the machine is a typical Node.js machine. Adding queues to Vert.x renders them both equal again. We can continue here for long.

We can't compare them both fair enough. The environment dictates the winner. It turns out that a thousand small-machines are faster than one big-machine; powerful enough like thousand small-machines. It also turns out that a thousand small-machines are cheaper than one big-machine; powerful enough like thousand small machines. In such environments, Node.js wins. Not even comparing developer experience and developer productivity. Hint: Download, install, run, GG ;-)

NodeJS is only faster for a small subset of things and then you also have to specify faster than what - in Java you have many options for serving data, either via Servlet-type options (in which case you also need to specify which servlet specification since the latest servlet specification can also do non-blocking reactive-type serving which should be on par with NodeJS), are we looking at VertX or what about Quasars and what about Scala actors which also compiles to Java byte-code. I suspect many of those options will give you the same performance as NodeJS for serving non-blocking data from a database.

NodeJS has the advantage with REGEX due to JavaScript being a dynamic language, Groovy (compiled to Java-bytecode) might be a contender here.

With regards to computation, the JVM is a lot faster than NodeJS according to these benchmarks which runs several computation-heavy loads on both NodeJS V6.2.1 and Java V1.8.0_92

The source-code for those benchmarks are available if you want to try and improve it.

In the end, it's about comparing apples to apples, having an event-loop type architecture is simply better and faster for serving non-blocking data in both Java and NodeJS

Hey world! Our paper writing service have a flexible working policy, allowing clients to request any service. Writing a term paper can vary in different phases; whether you want a full essay, a term paper cover page or a particular chapter, ensure that you indicate while ordering your work.