Albrecht Uhlmann
|
Re: Resource Manager threads ( Max number of threads)
|
Albrecht Uhlmann
12/18/2019 5:30 AM
post120113
|
Re: Resource Manager threads ( Max number of threads)
Hi Thomas,
I don't think that there are general recommendations that are always valid. It largely depends on the nature of your
resource manager. Here are some questions that you might want to ask yourself:
- How dynamic is the load on your resource manager expected? Is it a more steady state software where load oscillates
slightly around some avarage, or do you expect large load peaks, maybe even aperiodically?
- Can you actually handle multiple requests truly in parallel? For instance, if the resource manager needs to access
some backend storage or hardware to fulfil a task, then a high number of running threads would not help at all if they
all queue up on a lock on such a resource.
- Is a realtime response to a request necessary, and what is the expected reaction time?
So depending on how the answers look like, here are some properties that I came across:
- W.r.t. realtime, the most critical part is the "increment", because it is evaluated after receiving, but prior (!) to
handling a message. To be more clear, if the resource manager receives a message, and it finds that the number of
RECEIVE blocked threads is below lo_water, it creates "increment" new threads prior to calling the handler for the
message, which can spoil realtime responsiveness.
- If you expect large load peaks AND can truly handle them in parallel AND the handling may enter blocking states other
than acquiring internal locks, you can set the maximum above 20, so that the bulk work can be done faster.
- Maximum should be well above hi_water, since otherwise the thread pool would need todestroy threads even though there
are no more threads in RECEIVE blocked state.
- Alternatively, you can create steady-state pools by setting all attributes to the same value if you have rather
constant load on your resource manager.
W.r.t. resource usage, if the threads use a dynamically allocated stack I think in nowadays systems the resources used
by blocked threads weigh less than the resulting speed in software operation.
Hope this helps, just do some experiments and compare behaviour.
Regards,
Albrecht
|
|
|