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