On 11/3/05, Julian Foad <firstname.lastname@example.org> wrote:
> Erik Huelsmann wrote:
> > It looks like we use a lot of non-buffered file i/o:
> > Seaching for '(APR_READ or APR_WRITE) and not APR_BUFFERED' returns 31
> > files, whereas '(APR_READ or APR_WRITE) and APR_BUFFERED' only returns
> > 7.
> > Is it intentional that we haven't specified APR_BUFFERED so often?
> Hmm. What exactly is the benefit of this flag? Looking at the code, I see it
> causes APR to do its own buffering on top of what the C run-time library and/or
> OS already do. This presumably allows greater read/write efficiency (depending
> on the size of the transfers) at the cost of a time and memory overhead on the
> initial access.
> Does that balance out in our favour? I would expect an API to be designed so
> that it works best for the usual cases without any extra options being
> specified, which would imply that the buffered mode is only appropriate for
> some special cases, but that might not be so.
> Searching the web, I found an email discussion in 2000 questioning whether the
> buffering code is really wanted. Apache had httpd stopped using it, which
> casts doubt on its value.
From what I understand from a quick google search is that they stopped
using APR_BUFFERED for writing to logs. This may actually be logical,
since several processes may be writing to the same log file and
atomicity of line-by-line is a requirement because of it. Ofcourse
this can't be guaranteed if a file is being buffered.
Also, when serving up web-pages, you typically read somewhat larger
chunks which you'll want to serve up all at once. I don't think
there's much line-reading going on. Our code *does* do line reading
and writing and writing of smaller chunks.
> The other thing I found was a libapr tutorial which recommends requesting
> buffered mode in most cases.
> So, conflicting thoughts.
Maybe, maybe not. What if the above is true and it just doesn't make
sense for the purpose of httpd?
> One place it is probably not appropriate is when reading or writing a whole
> file at once.
And log files. yes.
> - Julian
Received on Thu Nov 3 16:45:01 2005