httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Slive <>
Subject Re: [users@httpd] mod_logio Performance hits?
Date Wed, 14 Sep 2005 02:06:57 GMT
On 9/13/05, Dan <> 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:
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.


The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message