Difference between standard verticle and worker verticle

[Rob Worsnop]

I am sure I'm being dense here, but I'm struggling to understand what is the difference, from the perspective of a developer, between a standard verticle and a (non-multithreaded) worker verticle.

If I set vertx.pool.eventloop.size to 30, and have 30 standard verticle instances, how is that different from setting vertx.pool.worker.size to 30 and having 30 worker verticles?

The difference I see in the doc is that a standard verticle instance will have a thread assigned to it forever, whereas a worker verticle will be assigned a different thread each time it does work. But how does that affect the developer, and make worker verticles suitable for blocking but not standard verticles?

[Alexander Lehmann]

Basically a standard verticle does all its work without blocking (or rather it should), so that you usually only need one. Even if you are processing many connections of a http server for example, you will still only need one verticle, since the operations necessary mostly spend time waiting and occasionally do some tiny bits of work. If you do something that blocks the operation of a thread like e.g. doing a JDBC operation, in a standard verticle everything else wouldn't go further during this time (to test this in an example program, just add a Thread.sleep(60000) somewhere and everything will freeze for a minute).
From a developers point of view, you are saving resources for everything that is being done in the standard verticle like opening files, waiting for network input etc, also waiting for an operation that is being done by a worker verticle, since you do not require a thread for each operation, while you are using a thread for an operation that is being done in the worker verticle, so you should use these only for the operations that really need it.

[Jordan Halterman]

Also, from a threading perspective, the difference is in which threads are assigned to the verticles. Normal verticles run on an event loop thread, so if they block then the event loop blocks, but workers run on threads separate from the event loop. That is the most important difference between the two.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Worsnop]

To clarify my question a bit: I know what developers are supposed to do (e.g., not block in a standard verticle). I understand the consequences of blocking in a busy application that has, say, 4 instances of a standard verticle backed by 4 event loop threads. The part I don't understand is, why wouldn't a developer simply create a large eventloop pool and use standard verticles for everything (other than the fact that ignoring documentation is usually a bad idea:))

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/4HdQvi2jIJ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

[Rob Worsnop]

Thanks. The phrasing of your answer helped me understand what I was missing (I think).

So in a world of standard verticles, there's an event loop whizzing around dispatching work to handlers. Since those handlers won't block, it's fine to make a simple synchronous call and then get back to the business of whizzing around.

In the worker verticle world, there's still an event loop whizzing around, but it has to dispatch work to handlers asynchronously via a thread pool, since the handlers will block.

So if the above is true, having a large event loop pool is not at all equivalent to having a large worker pool. Have I got it now?

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/4HdQvi2jIJ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

[Bogdan Mart]

I'm curious, can I make all verticles Worker?
Can woker verticle use Vertx Http client?
Does worker verticles has performance downside?

пятница, 13 июня 2014 г., 21:30:38 UTC+3 пользователь Jordan Halterman (kuujo) написал:

[Julien Viet]

On Aug 12, 2017, at 10:43 PM, Bogdan Mart <mart....@gmail.com> wrote:

I'm curious, can I make all verticles Worker?

that’s valid

Can woker verticle use Vertx Http client?

that’s valid too

Does worker verticles has performance downside?

the concurrency of workers can be much smaller than event loop verticles, i.e you might have tasks queuing on the underlying worker pool if you process lot of blocking tasks

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/871c4548-3a9a-42ad-9166-0f1562e645c2%40googlegroups.com.

[Bogdan Mart]

Thanks, bit cleared my understanding. Becouse I was looking at Docs, and got lot of misconcptions.

понедельник, 14 августа 2017 г., 15:53:18 UTC+3 пользователь Julien Viet написал:

[ad...@cs.miami.edu]

My understanding is that a worker verticle draws from the worker pool, but a standard draws from the event-loop pool.  Other than that, there is very little difference (they have different default settings for warning when a thread is being blocked too long).

I consider it more of an aspect of "intentional programming", where you use objects and idioms that well match the purpose and design of your application.  The worker thread is "for" longer running or IO blocking code.  Thus, the use of it communicates, quite strongly, your intention when using it.

-Adam

[Julien Viet]

the other difference is that the worker verticle will not have the same thread whereas the event-loop verticle will

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/51d7c2d4-ca0c-427f-b97b-a48079444d33%40googlegroups.com.

[javadevmtl]

Also vertx creates 2 x cores threads for the event pool (for regular verticles) + what ever for the worker pool.

Basically even when you have 1 event loop thread with 1 single instance of a regular verticle you can handle 10 of thousands++++ of events per second (this is how node.js works) The vertx bonus over node.js is that you can do that multiplied the number of cores you have and it manages it for you. With node.js you have to deploy multiple instance of your application to achieve the same and also have a way to load balance request between the multiple instance of node.js

Also if you go by the principle of 1 thread per 1 worker verticle (which basically equates to how servlet containers work), you would nee much more RAM and there would be far more context switching.

[Bill Davis]

I'm curious as to why this is - mainly that a event-loop verticle always runs in the same thread. Both types get single-thread guarantees if I understand it correctly.  A worker verticle will only be run by one thread at a time, just like an event-loop verticle (except for multi-threaded worker obviously).

So what's the advantage of always running in the same thread vs. a single thread at a time guarantee. The single thread guarantee seems to be more flexible.

[Bogdan Mart]

As far as I understand woker verticle would have overhead for thread synchronization.

Only thing that bothers me is that we have limited amount of Event loop threads (say 2 for single core machine) and if I have, say 10, verticles, and there could be situation, when most of work is made on first five, so first event loop is overloaded, and second is always empty.

According to doc regular verticle can't change thread, so on;y way to balance load is to undeploy/deploy again.

вторник, 29 августа 2017 г., 18:22:01 UTC+3 пользователь Bill Davis написал:

[Bill Davis]

That's kind of why I was asking about the event-loop verticles being locked to a single thread. I guess the solution (if that ever becomes a problem) would be to use worker verticles for that particular case. Although if you have "real" workers (meaning blocking) then that wouldn't work so well either.

Oh well, I'm just wondering, I don't have any performance issues with this in real life, and probably never will.