While stress testing our microservice build on Helidon MP, we found that the waiting time for the threads in handling requests increased linearly. We wanted to understand how Helidon MP decides on how many concurrent threads to create in its pool to manage incoming requests. Is it proportional to the number of cpu cores? Can I tweak/configure it?
Stress tested using JMeter sending 3 requests/second for 30 seconds.
Helidon defaults to 2x the core count. If your computations are too IO-centric and you find 2 x processor count too restrictive for your workloads, you can increase the workers further via a configuration on the WebServer.
The right proportion should be derived by a proper understanding of the nature of the workload, i.e. CPU bound vs IO bound. 2x is a good middle ground for most apps with CPU-bound loads mixed with intermittent and quick DB IO, but may lead to excessive queueing in case of slow/lengthy IO loads. If your computations are CPU centric then measure the relative performance starting with a number that is 1 more than the core count.
You can refer to the Helidon code for the same here.
