Very excited to announce the release of a new open source project Tektite. Tektite allows you to create topics (like Kafka or RedPanda) but also do processing (like Flink) and lots of other cool stuff, but all in one database. It’s a real database with its own log structured merge tree not a bolt-on on top of an existing DB or Kafka.

I haven't looked at this detail yet, but it should be noted that we haven't even optimised Vert.x yet so there should be plenty of scope for further improvement :)

(Disclaimer: I'm the Vert.x project lead)

The JVM does not doing any caching.

And artificially crippling Vert.x to a single core does not prove anything. Anybody who cares about performance will be using more than one core.

I've tested several combinations of blocking, non blocking, readFile, streams (pipe) and using chunked transfer encoding.

Results vary a little but all way below the Vert.x results.

See blog post for the stats.

Fair enough. After I wrote that I remembered that readFile wasn't blocking anyways, but it was too late to edit at that point.

People have already got Vert.x running on OpenShift and Heroku, and CloudFoundry support shouldn't be too much longer.

The flaw in your argument is that the server is spending 80% of its time reading a file from disk.

It's more than likely that it spends close to 0% of its time in disk access since its serving the same file, which will be cached by the OS in memory.

About the deprecated API. Earlier on I updated the results so they don't use that API, and I also added results for using streams. The results are slightly better but not by very much.

I use node but I kind of felt that this sort of scenario should be pretty obvious before you use it. I never use node to serve up static files, I use nginx instead. Small static files will be cached by the OS, as you said, which makes subsequent reads really quick. Since this is a small text file, it compresses really well over the wire too, so the time to serve up the request is lowered too. There's simply not much I/O to be a bottleneck in this benchmark scenario.

I wouldn't say that this is an unfair benchmark. But then I don't use node because it's "web scale". I use it because using javascript on the server, client, and on the wire (JSON) is pretty damn slick.

I'm interested in checkout out vert.x. But, this goes to everyone,let's not let this whole affair degenerate. Right tool for the right job. This particular benchmark scenario is explicitly the wrong way to use node. I'd suspect that if you were to change the readFile into an HTTP request however, the numbers might change. I also wouldn't be butt-hurt if vert.x still came out on top. There are still a ton of things to love about node.

Let's get on with our actual work now, shall we?

Vert.x has a hybrid model.

It has both event loops and a background thread pool, so you can choose which to run your task on depending on what kind of thing it is.

E.g. it's stupid to run long running or blocking actions on an event loop.

It's labelled badly, what is actually measured is req/resp per second.

I.e from request to corresponding response and how many of those it can do per second.

If you doubt the numbers please feel free to run them yourselves, all code is in github

Could you clarify that? Are you saying that if the response is sent within the same second that the request came in that it contributes to the metric?

Or would a response that is sent 30 seconds after the request came in contribute to the metric too?

It doesn't matter whether a request straddles a second or not in a throughput measuring benchmark when you saturate the system. A client would only count a request when its request call has returned. Runs it for N minutes, count up how many requests have completed, then divide the total with the time and you got req/sec.

Besides the benchmark has run for a minute. I doubt each request lasts 30 seconds.

+1.

The system is in steady state, i.e. queues of requests/responses aren't growing. Therefore it doesn't actually matter if you count the requests or the responses.

If you read the docs we specifically mention the "Fibonacci" farce.

Vert.x (unlike node) does not force you to do everything on the event loop. It has a hybrid model.

For things like long running calculations (e.g. Fibonacci) or calling blocking APIs, we support running them on a background thread pool so you don't end up doing stupid things on an event loop which are not appropriate for it.

Agreed, it would be good to have CommonJS support.

However, it's unlikely that node modules will work as is with Vert.x, since the API is different. (Unless someone writes a translation layer)