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. 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.