Re: Slow ICP under high loads (squid-1.2beta20 & 21)

From: Stewart Forster <slf@dont-contact.us>
Date: Wed, 27 May 1998 12:18:15 +1000

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

Hi Michael,

        The solution you propose will then suffer from starvation problems.
If a machine is capable of being driven to maximum with ICP requests and
responses, then there could arise situations where squid will starve (for
short periods) its current TCP transactions while it gets busy dealing
with ICP requests and replies.

        The current model allows for a fairly linear slowdown and shares
the load evenly and prevents starvation issues so I'm sticking to it. Sure
it burns a little more CPU, but currently we should be able to hit 300000
TCP hits/hour before we need to worry about slowdown from the CPU (using
167MHz UltraSparcII's).

        Of course, another approach is not to even bother calling
comm_poll_incoming and just call icpHandleUdp directly. It's a
possibility and under high loads would be faster than doing a poll()
which is almost always guaranteed to gave something waiting and then
do a icpHandleUdp anyway. It may be possible to code this in a nice
fashion where squid starts to discard certain checks (ie poll) once
the load gets high enough in order to preserve CPU/system calls.

        Stew.

> > For some time now I've been encountering very slow ICP responses from caches
> > under high load (sustained > 30 TCP & > 100 ICP requests/sec). I've managed
> > to trace this down to some code that was added a little while ago in the
> > effort to reduce CPU usage.
>
> Hmmm. I think the issue is more that icpHandleUdp() will only read one
> packet each time it's called. Changing icpHandleUdp to loop unto the
> recvfrom() returns EAGAIN is probably a better fix. (certainly, it's
> much cheaper on the CPU).
>
> Looking at the code, httpAccept() should possibly do the same thing.
>
> It should result in the same thruput, but with a lower CPU
> overhead. (and I think you're suffering the same CPU problem we are,
> aren't you? )

-- 
Stewart Forster (Snr. Development Engineer)
connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email: slf@connect.com.au   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666
--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:50 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:47 MST