On Tue, Jun 27, 2006, O'Brien, Kevin wrote: > Yes, and thanks for understanding what I'm trying to find out. > > I did run bootstrap after applying the patch and I ran an strace on the > process just to be sure that it's using epoll. > > My current working theory is that the service timers don't apply to the > diskd process. So, when using diskd the IO portion of the service times > is not accounted for. But that's just a theory... > > What still perplexes me is the increase in times as traffic decreases? > Seems odd... Its to do with the way squid handles checking for completed disk IO. It checks for disk IO at the beginning of every run through the main loop - and the main loop does have an implicit sleep if there's no network traffic (ie, if poll/epoll/select/kqueue don't pick up any changes to any filedescriptors.) Similarly - more network traffic (especially with epoll) results in many more times through the event loop - which means more chances to pick up completed disk IO. There'll be a point where you're checking often enough for diminishing returns to kick in (say, ~1000 times through the loop a second). I'm sure there's going to be some other influence - have you told us what "low traffic" is? Having some idea of throughput vs service time would be helpful. Check the average select loop time (in milliseconds) under the General Information page. Here's mine, ignoring the wrapped 32 bit counter: Select loop called: -802084506 times, -3.637 ms avg Adrian
