[Date Prev][Date Next]
Re: Thread pool efficiency
Howard Chu writes:
> Seems to have helped with 16 threads on the T5120, back-null peak went
> from 17,900 auths/sec at 32 connections to 18,500 auths/sec at 96
> Not much improvement with 24 threads, from a peak of 17,500 at 32
> connections to a peak of 17,000 at 60 connections. So the overall peak
> is a little slower, but it can handle a heavier load before maxing
Hm, ±3% with back-null. But I'm not sure how I got the decrease.
I've committed a slight cleanup now which might help.
I had swapped the tests before and after '&&' in pool_submit() here,
since the 1st now is shorter:
if (pool->ltp_vary_open_count > 0 &&
pool->ltp_open_count < pool->ltp_active_count+pool->ltp_pending_count)
The first checks if we may open a thread, the 2nd if we want to.
If slapd had less than 24 threads, there would be one extra test.
Could test with usleep(1) when adding/removing a task, first in
_submit() and next in _wrapper(), and see which one leads to more
And at the other mutexes I mentioned, for that matter.
>> (...) There are
>> several other singled shared mutexes which seem to be frequently used.
>> I'm far from sure of all of these, but here are some in slapd:
>> operation.c: slap_op_mutex, for slap_op_time().
Note ITS#5370. Can maybe remove it.