2

Vert.x seems to create upto 2 * NUM_OF_CORES event loop threads by default. And this seems to be a fairly old change (7 years+)

On a machine with 4 physical cores (8 logical cores with hyper-threading), it creates 16 event loop threads.

Shouldn't NUM_OF_CORES (i.e., 8 in above example) number of event loop threads be ideal?

Only explaination I could find was from Tim Fox (original author of vertx):

we use 2 * number of cores by default - in practice this gives better results as OSes don't always distribute threads evenly across cores.

But a few load tests I did gave better results when I used 8 instead of 16. So want to understand under what conditions should the default give better results?

mintuhouse
  • 449
  • 5
  • 16

1 Answers1

0

In optimal CPU bound calculations having about the same number of threads and logical cores is a good practice because we want out thread to use more CPU power as possible without interfering with other threads.

Usually Vert.x is not used for CPU intensive computations; for the most common usecases of Vert.x it might be helpful to have some more threads ready for beign used when needed, rather than having to create new ones on the go.

Why not using 10 * NUM_OF_CORES threads then? Because of the thread creation overhead and the risk of creating too many unused threads (that would lower the system performace). So this choise is (probably) the result of the tradeoff between thread responsiveness and waste of system resources.

Your benchmarks can produce bad results with 2 * NUM_OF_CORES for a variety or reasons, such as:

  • OS thread management (allocation time and context switches);
  • lack of system resouces (a lot of programs running with the one you are testing);
  • misuration issues (did the measure start before the thread allocation? did the test last for an amount of time that makes the thread creation time negligible?);
  • probably something else I can't figure out rn

Hope it helped!

Davprs
  • 1
  • 1