Re: Thread pool efficiency

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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