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

--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

On 27 May 98, at 11:17, Michael O'Reilly <michael@metal.iinet.net.au> wrote:

> > The solution you propose will then suffer from starvation problems.
>
> Indeed. That should be a
> for (loop = 0; loop < 16 ; ++loop) {
>
> instead of a while (1). This should produce exactly the same behaviour
> as calling comm_select_incoming() every time instead of every 16th
> time, but saves you all the poll/select calls.

 Are you sure that squid _should_ have perfect ICP response times always
 even when it is under high load?
   
> > 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.
>
> That's an interesting idea, and one I'd like to see carried a little
> further.

 poll takes several FD's under a single syscall, this conserves more CPU
 than skipping comm_poll_incoming in most cases. Although if already in
 icpHandleUdp it might make sense to suck icp socket empty before return,
 but this only if you are sure you need zero-delay ICP.

 What about special thread that sits in poll() for incoming sockets, and
 whenever something interesting happens there, sets global var to make
 note of that. Then, in comm_select, call handlers only if there is known
 ready socket waiting.

----------------------------------------------------------------------
 Andres Kroonmaa mail: andre@online.ee
 Network Manager
 Organization: MicroLink Online Tel: 6308 909
 Tallinn, Sakala 19 Pho: +372 6308 909
 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
----------------------------------------------------------------------

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:50 MDT