[Date Prev][Date Next]
Re: Thread pool efficiency
Howard Chu writes:
> I guess so. We can try to minimize that by assigning jobs to the
> shortest queues. On a lightly loaded server, there will probably be at
> least one empty queue, so jobs will always be dispatched quickly.
> On a heavily loaded server, all jobs are going to experience longer
> delays anyway, so I don't think the worst case can deviate very far
> from the average case.
It can if one uses one slow and one fast backend.
Or with operations like adding a member to a 20000-member posixGroup.
I just did that, it took 0.7 seconds with back-bdb. In the mean time,
slapd sent 350 other results (not counting search result entries) and
accepted 65 connections. Mostly for operations against another
database. I don't know how similar the relative times would be on a
heavily loaded server though.
BTW, is the problem that each operation locks pool->ltp_mutex 2-3 times,
or is it the amount of time it is kept locked? Most tests which
pool_<submit/wrapper>() do with ltp_mutex locked, could be precomputed.