How to optimize Vertx to use multi cores instead of use single core on multi-core server

[Idan Fridman]

I have single instance vertx which includes couple of Verticles:

I am starting vertx with verticles this way:

public static void main(String[] args) throws Exception {
    

..

     int vertxWorkerPoolSize=40;
    ClusterManager mgr = new HazelcastClusterManager();
    VertxOptions options = new VertxOptions().setClusterManager(mgr);
    options.setHAEnabled(true);
    
    DeploymentOptions deploymentOptions = new DeploymentOptions().setConfig(config);
    deploymentOptions.setHa(true);
    Vertx.clusteredVertx(options, res -> {
        if (res.succeeded()) {
 
            Vertx vertx = res.result();
            deployVerticles(context, deploymentOptions, vertx);
        } else {
            logger.error("Error initiating Vertx cluster", res.cause());
        }
    });
}

private static void deployVerticles(ApplicationContext context, DeploymentOptions deploymentOptions, Vertx vertx) {
    vertx.deployVerticle(new FirstVerticle, deploymentOptions);

    vertx.deployVerticle(new SecondVerticle, deploymentOptions);
...
}
}

However I payed attention that on my multi-core machine only one is working. and it's almost on 100% capacity

I did top in the linux machine:

1. How can I spread vertx to balance the load using all cores?

2. Should I pay attention to other metrics after analyzing the linux- top result.

Thanks.

[Steffen Reichert]

I don’t know what the top output should tell me. If you want your vertx to use a specified number of cores of your system, try starting it by using the following option

-Dvertx.options.eventLoopPoolSize=<number of cores>

--
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/b39f8708-f634-42b0-a6e4-c6c6f65288b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Fox]

This is very hard to answer without knowing what your verticles do and how many of each one you deploy.

[Tim Fox]

This shouldn't be necessary as Vert.x will default number of event loops to number of cores * 2 on the machine.

The issue here is probably more to do with the function and number of verticles that have been deployed.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/AEC1254C-1C99-457E-A01E-AA55C1706735%40gmail.com.

[Idan Fridman]

Tim,

You can see exactly how many verticles I have deployed (I pasted my code) - which is one per verticle (FirstVerticle, SecondVerticle)

You suggest to to deploy more verticles and automatically ill have additional cpu's involved ? or should I provide u additional information to nail this.

Thanks.

[Tim Fox]

On 20/04/16 16:08, Idan Fridman wrote:

Tim,

You can see exactly how many verticles I have deployed (I pasted my code) - which is one per verticle (FirstVerticle, SecondVerticle)

You suggest to to deploy more verticles and automatically ill have additional cpu's involved ? or should I provide u additional information to nail this.

We'd need to know what these verticles do. Just deploying a verticle doesn't mean it will use any CPU, it completely depends on what the verticle does.

-- 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/7dcc55f7-3a8d-4bc5-8e35-50a8fe2a7a31%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[Idan Fridman]

We'd need to know what these verticles do. Just deploying a verticle doesn't mean it will use any CPU, it completely depends on what the verticle does.

The verticle do some business logic ( adding to redis, adding to other datasource, some internal logic..) I am not sure how can I explain all the internal logic of our verticles and by that youll be able to tell me how to spread this load on diff CPU's ? 

if every vertical receive a request (which might be chained to other verticles) cant we in some way to balance the load using diff cpu's ?

[Jez P]

What do you mean by "adding to other datasource"? JDBC? If so that's going to spend a lot of its time blocked. 

What happens if you use, for example 10 instances of each verticle? Have you tried that? Any verticle instance can be bound to only one event loop thread. So if you only have two verticles, then at best you'll only have two threads in use for event loops, and therefore only, at most, two CPU cores being used.

[Tim Fox]

This kind of question is really impossible to answer without more information. If you can't show some code maybe you could explain in as much detail as possible what your verticles do and how they interact with one another?

We can't give advice on tuning something without first seeing what needs to be tuned.

-- 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/e9b8c111-6ca1-4f00-8749-4b79de489d04%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[Jez P]

And given there are only two verticles, it should actually be quite easy to detail what i/o they are doing, whether it is blocking (and if not blocking what modules/drivers you're using) etc. I appreciate you may not be able to share your logic but you could enumerate the basic logical flows and the i/o involved including how you are doing it. You've told us very little of the information which would be useful in helping you.

So please help us help you :)

[Jochen Bedersdorfer]

Remember that a verticle instance is bound to exactly one thread.

If you only deploy two verticles, the best you can hope for is 2 event loops being busy.

Try deploying several instances of the same verticle (that assumes that there's no reliance on just having a single verticle for your business function).

(i.e. use setInstances in DeploymentOptions)

Note: if you can only have one instance for a verticle, because it holds some cluster-wide state, at least consider using a multi-threaded worker verticle and deal with proper synchronization.

However, you can only hope to keep all of your cores busy if you consider a verticle as a unit of work that can be parallelized.

Hope that helps,

 Jochen