On 9/13/05, Dan <lists@xxxxxxxxxxx> wrote: > Hi Folks, > > We've encountered a bit of a problem with Apache2. > > Apparently to improve performance, when apache2 logs the respose size > in the access log, it logs the 'expected' file size, not the amount > of data sent out on the wire. It seems to get this information from > the filesize of the file being served. Here's where it becomes a > problem: > > * If someone downloads only say 100MB of a 650MB ISO image, apache > logs the 650MB figure. > > * If someone uses a download manager to download a file in chunks, > apache logs the overall size of the file, not the size of each chunk > sent. > > As you can imagine, this causes havoc with traffic/log analysers. > They're saying our outbound data is far far greater than we're > physically capable of pushing. > > Now, someone mentioned to me that mod_logio can come closer to > logging the actual data sent on the wire (albeit with the headers > included). My query is, what sort of performance hit have people > encountered when using this module, especially in a large-scale high- > output environment (we're talking 1000 concurrent connections, many > of them downloading large - 200MB+ - files). > > Would the performance hit be enough to consider back-tracking to > Apache1.3 (which correctly logs the bytes sent, rather than the > 'expected' bytes to be sent) instead of Apache2? I don't run mod_logio on a busy server, but if you take a look at the source code: http://svn.apache.org/viewcvs.cgi/httpd/httpd/branches/2.0.x/modules/loggers/mod_logio.c?rev=151405&view=markup you'll see that it doesn't do anything complicated. I would guess that the performance effect would be too small to measure, except perhaps in some edge cases. And the performance benefits you get from sendfile/threading/etc in 2.0 will surely dawrf any cost of mod_logio. Joshua. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|