Re: squid-users-digest Digest V97 #62

I had exactly the same problems with the redirector. I lifted it to
the maximum of 32 processes, and it was still queuing requests. The
redirector processes were simple perl scripts of the form..
        $| = 1;
        while (<>) { s/xxxx/yyyy/; print }

and doing an strace on them confirmed that they were NOT doing
blocking I/O, that the only system calls the script was doing was
        read(...);
        write(...);
and the the read - write gap was < 1ms. (i.e. immediate turn
around). Squid however was still frequently using all 32 of them!

My conclusion was that squid was doing the checking in the wrong order
or something, and was introducing a fairly high latency into the
re-writters.

No idea why. We couldn't take the performance hit, so I turned it off
again.

Michael.

Ps. the squid was PPro 200, 256Meg ram, 8 gig cache, running at around
55,000 hits/hour.

In message <199703171533.HAA26679@nlanr.net>, squid-users-digest-request@nlanr.
net writes:
> Date: Fri, 14 Mar 97 18:34:09 -0800
> From: Duane Wessels <wessels>
> To: H.Bekker@cc.ruu.nl (Henny Bekker)
> Subject: Re: Number of redirect processes ...
>
> The redirector becomes busy after the request has passed
> the access control checks. It becomes available as soon as
> it finishes writing back the answer. It does not stay busy
> until the transfer completes.
>
> When all redirectors are busy, additional requests are queued up,
> so yes, they block.
>
> I would think that 32 is plenty. Maybe you need to make sure
> your redirectors are not doing any buffering of input or output?
>
> Duane W.
Received on Mon Mar 17 1997 - 23:14:39 MST