In what way vert.x is better than node?

[Guillaume Laforge]

Hi there,

Some colleagues from a past life noticed vert.x on InfoQ, and had already exposure to Node.js.

I told them that vert.x had great performance compared to node, that it was "more" async, etc. but I definitely lack argumentation to prove vert.x is a better alternative.

It would be nice to have a FAQ page explaining such things, and also pointing at a proper benchmark.

The first remark I got was (translated from French) along the lines of: I don't see why vert.x would be faster.

So an explanation on why it's faster, and with some figures of a benchmark to prove the point would be great.

There were also some concerns in the sense that vert.x is pretty new and doesn't progress at the pace of node, but that's always the case with outsiders anyway, so it's kind of a dull point.

I was explaining that everything was fully async, perhaps more than node.

Am I wrong in saying that?

For example, the guy was saying that everything is async in node, even things like the redis, memcached, file system driver.

Is it totally true? And is vert.x really doing better in that area?

I was pointing at the fact that vert.x was multithreaded, that it had several event loops, as many as the number of cores, and that it made things work in a more fluid way, as there's less waiting / blocking on a single event loop. But the guy was saying that you just need to start as many node as cores, and that it worked well.

However, he reckoned that due to multi processes, you had no shared memory, you could have issues with logs, and that other projects like Ruby with Unicorn had the same issues, but that it wasn't too hard to deal with that (without further details).

So in benchmarks, is vert.x running better with multithreading than one standalone node.js per core?

We need answers to such common questions to be able to properly advertise vert.x and show the world it's a great alternative to Node.js :-)

I'm looking forward to reading your answers and to spreading the word!

--
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/

Social: @glaforge / Google+

[Pid]

On 05/05/2012 15:57, Guillaume Laforge wrote:
> Hi there,
>
> Some colleagues from a past life noticed vert.x on InfoQ, and had
> already exposure to Node.js.
> I told them that vert.x had great performance compared to node, that it
> was "more" async, etc. but I definitely lack argumentation to prove
> vert.x is a better alternative.
> It would be nice to have a FAQ page explaining such things, and also
> pointing at a proper benchmark.

I think there's a tentative plan to run some proper performance tests.

> The first remark I got was (translated from French) along the lines of:
> I don't see why vert.x would be faster.

Sounds a bit defensive.

> So an explanation on why it's faster, and with some figures of a
> benchmark to prove the point would be great.

Seems fair.

> There were also some concerns in the sense that vert.x is pretty new and
> doesn't progress at the pace of node, but that's always the case with
> outsiders anyway, so it's kind of a dull point.

I'd say it was progressing faster *because* it's new - less backwards
compatibility to worry about.

> I was explaining that everything was fully async, perhaps more than node.
> Am I wrong in saying that?
>
> For example, the guy was saying that everything is async in node, even
> things like the redis, memcached, file system driver.
> Is it totally true? And is vert.x really doing better in that area?
>
> I was pointing at the fact that vert.x was multithreaded, that it had
> several event loops, as many as the number of cores, and that it made
> things work in a more fluid way, as there's less waiting / blocking on a
> single event loop. But the guy was saying that you just need to start as
> many node as cores, and that it worked well.

:p

Anyone can scale horizontally. It's hardly a winning argument.

> However, he reckoned that due to multi processes, you had no shared
> memory, you could have issues with logs, and that other projects like
> Ruby with Unicorn had the same issues, but that it wasn't too hard to
> deal with that (without further details).
>
> So in benchmarks, is vert.x running better with multithreading than one
> standalone node.js per core?

I guess we'll see. :)


p

> We need answers to such common questions to be able to properly
> advertise vert.x and show the world it's a great alternative to Node.js :-)
>
> I'm looking forward to reading your answers and to spreading the word!
>
> --
> Guillaume Laforge
> Groovy Project Manager
> SpringSource, a division of VMware
>
> Blog: http://glaforge.appspot.com/

> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>


--

[key:62590808]

[Tim Fox]

On Saturday, May 5, 2012 3:57:58 PM UTC+1, Guillaume Laforge wrote:

Hi there,

Some colleagues from a past life noticed vert.x on InfoQ, and had already exposure to Node.js.

I told them that vert.x had great performance compared to node, that it was "more" async, etc. but I definitely lack argumentation to prove vert.x is a better alternative.

It would be nice to have a FAQ page explaining such things, and also pointing at a proper benchmark.

+1

 

The first remark I got was (translated from French) along the lines of: I don't see why vert.x would be faster.

Some things in vert.x just appear to be faster, full stop. E.g. serving files from the file system. The JVM appears to be faster than V8 for most code (there are some exceptions, e.g. regex)

Also vert.x scales far more easily than node.js. For example if I create a simple webserver it will scale across available cores just by specifying the -instances command line param (see the front page of the web site). With node.js you have to manually start N instances, and then implement glue code (cluster module) to farm out requests between the instances.

Even if you do that the performance of N node.js servers is significantly poorer than a single Vert.x server with -instances N (in the tests I did anyway).

 

So an explanation on why it's faster, and with some figures of a benchmark to prove the point would be great.

Yes, would definitely like to get some benchmarks out. Main problem I have is lack of hardware :(

 

There were also some concerns in the sense that vert.x is pretty new and doesn't progress at the pace of node, but that's always the case with outsiders anyway, so it's kind of a dull point.

I'd say the opposite actually. Vert.x is progressing very fast at the moment, much faster than node. Node has been around for about 3 years. Vert.x less than 1 year, during which time we have reached feature parity.

 

I was explaining that everything was fully async, perhaps more than node.

Am I wrong in saying that?

Probably the same - node has some blocking stuff in the file API, so does vert.x.

About event loops: Vert.x has a hybrid model. With node you have to run everything on event loop, but this is stupid for some things like long running computations, or calling legacy blocking APIs. So vert.x allows you to use event loops for short running stuff but also supports workers

 

For example, the guy was saying that everything is async in node, even things like the redis, memcached, file system driver.

Is it totally true? And is vert.x really doing better in that area?

I wrote a 100% async redis driver some time back - I need to resurrect it.

As mentioned above, one advantage of vert.x over node.js is it doesn't force you to run everything on an event loop, so you can more easily use legacy blocking APIs (e.g. JDBC). You can't do this with node afaik.

 

I was pointing at the fact that vert.x was multithreaded, that it had several event loops, as many as the number of cores, and that it made things work in a more fluid way, as there's less waiting / blocking on a single event loop. But the guy was saying that you just need to start as many node as cores, and that it worked well.

Yes, a node.js instance is single threaded, so you have to start N instances to use N cores. This is a pita since you need to manually manage the instances, and also write glue code / load balancing code to farm our requests. If your app is not stateless you have a bigger problem in how do you share state between those nodes - most probably you will have to dump it in a DB. With vert.x each verticle instance can share immutable state in process.

 

However, he reckoned that due to multi processes, you had no shared memory, you could have issues with logs, and that other projects like Ruby with Unicorn had the same issues, but that it wasn't too hard to deal with that (without further details).

So in benchmarks, is vert.x running better with multithreading than one standalone node.js per core?

In my tests so far, yes, one instance of vert.x processes more work (this was serving http) than N node.js instances. 

[Wilson MacGyver]

I've been playing around with some benchmarks on ec2 (micro/small/large) When you say you lack hardware, I assume you want access to bare metal hardware?

[Peter Ledbrook]

>> There were also some concerns in the sense that vert.x is pretty new and
>> doesn't progress at the pace of node, but that's always the case with
>> outsiders anyway, so it's kind of a dull point.
>
>
> I'd say the opposite actually. Vert.x is progressing very fast at the
> moment, much faster than node. Node has been around for about 3 years.
> Vert.x less than 1 year, during which time we have reached feature parity.

Don't forget that the number of Node.js modules is growing very
rapidly. I suspect that's why he said vert.x doesn't progress at the
same pace. These days, the ecosystem is at least as important as the
core technology.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

[Guillaume Laforge]

On Wed, May 9, 2012 at 10:50 AM, Peter Ledbrook <pe...@cacoethes.co.uk> wrote:

>> There were also some concerns in the sense that vert.x is pretty new and
>> doesn't progress at the pace of node, but that's always the case with
>> outsiders anyway, so it's kind of a dull point.
>
>
> I'd say the opposite actually. Vert.x is progressing very fast at the
> moment, much faster than node. Node has been around for about 3 years.
> Vert.x less than 1 year, during which time we have reached feature parity.

Don't forget that the number of Node.js modules is growing very
rapidly. I suspect that's why he said vert.x doesn't progress at the
same pace. These days, the ecosystem is at least as important as the
core technology.

Agreed, although Vert.x has the advantage of being part of the wider Java ecosystem, which provides really tons of mature libraries, compared to what existed only recently in the JavaScript space.

So even if those libraries are not necessarily made into Vert.x modules per se, they can often be used as is directly already, without having to reinvent the wheel.

[Tim Fox]

Yeah, bare metal. VMware (unsurprisingly) offered me some virtualised stuff, but this isn't too good for benchmarking since you're contending with other unknown users for the CPU and network.

[Wilson MacGyver]

ah ok, was going to offer some amazon instances to you :)

--
Omnem crede diem tibi diluxisse supremum.

[Pid]

On 09/05/2012 11:01, Guillaume Laforge wrote:
> On Wed, May 9, 2012 at 10:50 AM, Peter Ledbrook <pe...@cacoethes.co.uk
> <mailto:pe...@cacoethes.co.uk>> wrote:
>
> >> There were also some concerns in the sense that vert.x is pretty
> new and
> >> doesn't progress at the pace of node, but that's always the case with
> >> outsiders anyway, so it's kind of a dull point.
> >
> >
> > I'd say the opposite actually. Vert.x is progressing very fast at the
> > moment, much faster than node. Node has been around for about 3 years.
> > Vert.x less than 1 year, during which time we have reached feature
> parity.
>
> Don't forget that the number of Node.js modules is growing very
> rapidly. I suspect that's why he said vert.x doesn't progress at the
> same pace. These days, the ecosystem is at least as important as the
> core technology.
>
>
> Agreed, although Vert.x has the advantage of being part of the wider
> Java ecosystem, which provides really tons of mature libraries, compared
> to what existed only recently in the JavaScript space.
> So even if those libraries are not necessarily made into Vert.x modules
> per se, they can often be used as is directly already, without having to
> reinvent the wheel.

+1


p

> --
> Guillaume Laforge
> Groovy Project Manager
> SpringSource, a division of VMware
>
> Blog: http://glaforge.appspot.com/