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.
Great...
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.
Did you try that with sorted values?
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.