Re: [squid-users] Squid Performance Issues - reproduced

Andres Kroonmaa wrote:

> nono, its quite opposite. on SMP system other cpu is used so faintingly
> little that its almost irrelevant. Most point of multiple threads in IO is just
> to make several IO requests pending concurrently. Most of the time IO
> threads are blocked in OS anyway, and thats good, UP or SMP system.
> So imo the more threads we can get concurrently, the better. Signalling
> too many threads just eats up main thread cpu time. Also requesting
> things that almost never block, like file write requests.

Sorry, I do not quite follow here.

There is quite many I/O operations that rarely block. The completetion
of these we rather have signalled back to the main thread before we
enter poll/select again, and for this to happen they need to get started
while we process other events.

I agree that the signalling can be optimized a bit, but if the number of
threads are reasonable then there is not much to gain. A cond_signal
while no threads are blocked on the condition should not be at all a
heavy operation, and if there is threads blocked we rather have them
started as there probably is no thread running or the ones running are
blocked on I/O.

However, it is very easy to measure if this is a problem. Just insert a
counter counting how often threads gets awakened finding there is no
requests in the requests queue. If found that this is high in relation
to the number of requests processed by the thread then there is a
problem.

Regards
Henrik
Received on Sat Jan 04 2003 - 08:09:26 MST