On Wed, 11 Oct 2006, Graham Leggett wrote:
This patch implements copying a file in the background so the client
initiating the caching can get the file delivered by read-while-caching
instead of having to wait for the file to finish.
Something that Joe Orton raised, and that I've been looking into in more
detail.
The copy_body function currently only supports file buckets, which
specifically excludes buckets generated by say mod_proxy, or mod_cgi. From my
testing, for these non file buckets, the response is downloaded and cached
fully, then the client gets fed data. Initially I understood this as an
optimisation specific to files, assuming that file buckets were the only
buckets that could potentially exceed available RAM, but the case where non
file buckets are present is currently unhandled.
I don't have enough knowledge of httpd internals to be sure, but
doesn't the data-generating types insert flush buckets in the stream
to avoid this? That said, mod_disk_cache seems to be totally unaware
of flush buckets so I'm either barking up the wrong tree, it's handled
on a higher level or it isn't handled.
In theory, the copy body should be able to read from any brigade, rather than
just a file brigade, in such a way that it doesn't try and load 4.7GB into
RAM at once for file buckets.
The original reason for copy_body() was to have something that could
be used in a background thread, and the only thing I'm sure can be
copied in the background is plain files. Everything else must be
handled the "old" way.
I am jetlagged right now and can't think straight any more today, will carry
on looking at this tomorrow :)
OK. I'll be away for a week or so and might lag quite a bit in
replying to stuff.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---------------------------------------------------------------------------
Huh? What? Am I on-line?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
