this is all true, but am I wrong in thinking that logging to disk incurs yet more disk I/O, and for both refers *and* access, then that's 2 disk writes per object request ? for the amount of traffic that we're doing, I'm guessing that it might be a bit much. but I could be wrong, of course. :) -j ----- Original Message ---- From: Henrik Nordstrom <hno@xxxxxxxxxxxxxxx> To: john allspaw <jallspaw@xxxxxxxxx> Cc: Squid Users <squid-users@xxxxxxxxxxxxxxx> Sent: Fri Aug 12 04:55:13 2005 Subject: Re: any updates/info on using spread with squid for logging ? On Thu, 11 Aug 2005, john allspaw wrote: > yeah, not really a good option, because that defeats some of the reasons why we're using spread: > > - don't have to have logs go to disk Why? They only go to disk for a short while (lets say a hour), and only as a shadow copy of what is being sent to your log service. The only purpose of this file is as a non-blocking communication medium from where your log service can read the data while it is being logged by Squid. > - don't have to deal with log rotation on an entire farm of squids Again, this log rotation is internal to each squid box. > - can watch/analyze logs on one aggregated file. This you do get by the proposed solution. Instead of logging to a pipe which will slow down Squid if your log processor can not keep up, have Squid write to a file and the log processor read from the same file while Squid is writing to it. This allows for a considerably larger buffer than what is provided by pipes. Log rotation is used in this kind of configuration only as means of not running out of local disk space due to the log files growing overly large. The on-disk log file isn't really used as such, it's just a temporary scratch media while the logs is sent to your log service. Regards Henrik
