purplefox

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.

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

Hopefully Scala won't be too long :)

+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.

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.

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

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)

Yes indeed. You can mix and match Java, JavaScript, Ruby and Groovy in the same app. We hope to support more languages going ahead (e.g. Java, Scala, ...)

Yes, of course in a real web server you'd make sure you do the checks ;) The documentation actually mentions this point explicitly :)

Yes, I meant threads ;) E.g. A web server using node.js on a 32 core server. You would have to manually manage 32 instances of node, and use a load balancer or the cluster module in order to route requests to the instances. With vert.x you just start one instance and from the command line you tell it how many instances to start. It then scales over your cores, no glue code or cluster module to write. (There's an example of this on the front page of the website).

If the wire protocol for the driver is published, then you can write a 100% async driver for it. I.e. no threads blocking, ever. In fact, I already did this for redis and vert.x (I will dig out the code for this some time).

If you are dealing with something where you don't know what the wire protocol is and you just have a blocking client library to play with (e.g. JDBC - JDBC is, by definition blocking - see the JDBC API), then you can't do much but to wrap the blocking api in an async facade and limit the number of threads that block at any one time. This is exactly what we do in vert.x. We accept the fact that many libraries in the Java world are blocking (e.g. JDBC) so we allow you to use them by running them on as a worker. This is one area where we differ from node.js. Node.js makes you run everything on an event loop. This is just silly for some things, e.g. long running computations (remember the Fibonacci number affair?), or calling blocking apis. With vert.x you run "event-loopy" things on the event loop but you can run "non event-loopy" things on a worker. It's a hybrid.

Yes, vert.x should work directly on Windows. I shall update the wiki accordingly :)

Fibers (or equivalent constructs) aren't supported by all the languages that Vert.x supports (e.g. Java) so we can't really support something like that until we can do it in all the langs.

I know Fibers/Green threads are all the rage right now, and it is certainly something to keep an eye on, but I am not entirely convinced that roll your own threading is going to be any more performant than what the kernel can do.

If we can find a way of implementing fibers efficiently, that supports millions of fibers on a single JVM instance, I would be interested.

That's right. If you use the sendFile() method and you're on an OS that supports it, then the kernel will do the copying directly from file to socket for you.

You can also serve files in the more conventional "node.js-style" way (i.e. pump the buffers manually from file to socket) if you like. It's just slower than getting the kernel to do the work for you.

Works fine here:

https://gist.github.com/2594983

Are you sure you're not looking at the github tags, rather than the downloads?

(Tim Fox here, project lead)

The core api is similar to node.js, but that API is available in not just JavaScript, but in Ruby, Java and Groovy.

Unlike node.js it also includes websockets and sockjs support and a distributed event bus so you can link together multiple nodes on the server side and extending into client side JavaScript.

Since it runs on the JVM and has real threading (unlike V8) it means you can scale with a single instance far better than you can with node.js. And you don't have to resort to hacky forks in order to scale it over multiple cores.

In my perf tests so far, performance (far) exceeds node.js for some simple HTTP test cases. I will hopefully publish some results in the next few weeks when we release 1.0 final.

So one way of thinking about it is node.js, on steroids and not just for JavaScript.

Vert.x is a VMware sponsored project.

If you think node.js is fast try http://vertx.io.

It's like node but isn't single threaded so scales over multiple cores without having to fork. Also it's polyglot so you can don't have to use JS if you don't want.

I'm hoping to publish some performance results vs node.js before our 1.0.final release in the next few weeks.