Vertx multi-thread vs Multi-workers

[TY]

Hi 

Would like to know which one will have better performance & provide better scalability? 

Example:

We have a worker verticle that does some blocking calls (http requests), and the verticle does not have any state or instance variables.  

We are trying two different scaling approaches.  

1.  Set Multi-threads = true for the worker verticle

2.  Increase the number of worker verticle and set mutli-threads to false

We ran some tests and DONT see much performance differences and we found 

1) If we set mutli-threads = true, the bottleneck is the # of the background threads (worker threads)

2) If we set mutli-threads = false, to achieve the same performance as #1, we need to increase the # of background threads as well as the # of worker instances

Thanks

TY

[Mumuney Abdlquadri]

Please implement based on best practice in docs. You optimize as you go.

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

[bytor99999]

The docs doesn't mention either way. If you have seen it, please provide a link.

On our application, we only deploy one instance of our Worker Verticle, but is is marked as multi-threaded and set the thread pool size and it has worked fine for us.

Mark

[Tim Fox]

On 22/06/15 18:08, TY wrote:

Hi 

Would like to know which one will have better performance & provide better scalability?

Neither.

Performance will be the same as in both cases you have the same number of threads blocking on your http requests (i.e. all threads in the worker pool).

Your performance issue here is not because of standard worker vs multi-threaded worker, it's because you're blocking!

That's why I always say, don't use blocking code unless you really have no choice.

Example:

We have a worker verticle that does some blocking calls (http requests), and the verticle does not have any state or instance variables.  

We are trying two different scaling approaches.  

1.  Set Multi-threads = true for the worker verticle

2.  Increase the number of worker verticle and set mutli-threads to false

We ran some tests and DONT see much performance differences and we found 

1) If we set mutli-threads = true, the bottleneck is the # of the background threads (worker threads)

2) If we set mutli-threads = false, to achieve the same performance as #1, we need to increase the # of background threads as well as the # of worker instances

Thanks

TY

[Tim Fox]

On 23/06/15 08:46, Tim Fox wrote:

On 22/06/15 18:08, TY wrote:

Hi 

Would like to know which one will have better performance & provide better scalability?

Neither.

Performance will be the same as in both cases you have the same number of threads blocking on your http requests (i.e. all threads in the worker pool).

Your performance issue here is not because of standard worker vs multi-threaded worker, it's because you're blocking!

That's why I always say, don't use blocking code unless you really have no choice.

Let's say you have 100 threads in your worker pool.

Let's say each blocking HTTP request takes 100ms to run.

Then clearly you can never have more than 1000 req/s - that's not a Vert.x limitation, it's a laws of physics limitation ;)

Even if you target HTTP servers can cope with way more load than that, your system throughput will be limited by the thread pool size. And you can't just go on increasing thread pool size for ever.

I hope this is a good illustration why blocking is bad.