Re: possible problem with gettimeofday

> oskar@is.co.za writes:
>
> >I midified it a little and every time squid fell over. I then tried
> >on a FreeBSD machine, and it didn't fall over, but the load
> >on the machine went crazy - a ktrace showed that it was doing thousands
> >of "gettimeofday" calls....
> >
> >Normal?
> >
> >>From the first guess, it seems that squid walks through all of the
> >filehandles calling gettimeofday for each of them...
>
> Whats happening is this:
>
> comm_select_incoming() gets called in comm_select() after every FD
> with I/O pending. The reason is to keep the ICP requests flowing
> quickly and to prevent the HTTP socket listen queue from getting
> too backed up. gettimeofday() is called in comm_select_incoming();
> the only reason for that would be to get more accurate timestamps
> and delays in the log file.
>
> Probably we need to be smarter about how often comm_select_incoming()
> gets called. It should be possible to measure the rate of ICP
> and HTTP connections compared to the number of active FD's and, only
> all comm_select_incoming(), say every 5 FD's.
>
> Duane W.

    I would like to second Oskar. Squid tends to call gettimeofday() much
 too frequently. To my understanding squid's getCurrentTime() serves two
 purposes:
 1) to measure accurately time taken to serve any request (ICP or TCP)
 2) keeptrack with a 1 sec granularity socket timeouts.

 To accomplish first one, we need to call getCurrentTime() only two times:
    1) after incoming requests is read, and
    2) after final data is sent out.
 No need to call it more frequently, is it?

 To do the second, we might make use of asyncronous signal notification:
 install a ALRM signal handler that calls getCurrentTime() and sets
 squidCurTime, and reshedules itself till later after 1 second.
 Then, other parts of Squid need not to call system call but use global
 variable directly - much faster. And only when subsecond precision is
 important, call getCurrentTime() extra time.

 And regarding comm_select_incoming(), I'd suggest to use async notification
 here too - ioctl() permits requesting SIGPOLL on any interesting event on
 the stream - that should be "incoming" sockets. I guess this should be
 pretty portable also, although i'm not very confident regarding any problems
 that might arise when servicing socket io from signal handler... For one,
 we must be pretty sure not to loose signals.
 In ideal case we need not call comm_select_incoming at all to poll for
 incoming events, they will be serviced asyncronously when occuring.

 PS. polling incoming every say 5 FD's is problematic, because squid would
 not then handle burst incoming traffic very well, effectively limiting it
 to some previously measured rate.

 PPS. And in my personal opinion, giving incoming http requests priority
 over established one's makes squid prone to denial-of-service attacks.
 IMO if squid cannot service all ready sockets in a row, it should not
 accept any further http connections. Otherways, if incoming connections
 are coming faster than server is able to service others in tcp timeouts
 (and user's human timeouts), we can end up with a server that is accepting
 connections blistering fast, but doing nothing useful...

-------------------------------------------------------------------
 Andres Kroonmaa Telefon: 6308 909
 Network administrator
 E-mail: andre@ml.ee Phone: (+372) 6308 909
 Organization: MicroLink Online
 EE0001, Estonia, Tallinn, Sakala 19 Fax: (+372) 6308 901
-------------------------------------------------------------------
Received on Tue Jul 29 2003 - 13:15:41 MDT