httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: core_output_filter buffering for keepalives? Re: Apache 2.0 Numbers
Date Mon, 24 Jun 2002 06:12:39 GMT
On Mon, 24 Jun 2002, Bill Stoddard wrote:

> Yack... just noticed this too. This renders the fd cache (in
> mod_mem_cache) virtually useless.  Not sure why we cannot setaside a fd.

You can.  The buckets code is smart enough to (a) take no action if the
apr_file_t is already in an ancestor pool of the one you're asking to
setaside into and (b) just use apr_file_dup() to get it into the requested
pool otherwise to handle the pool cleanup/lifetime issues.

It's the core_output_filter that's doing an apr_bucket_read() /
apr_brigade_write() here.  Presumably to minimize the number of buffers
that will have to be passed to writev() later.

That could be changed pretty easily, and the mmap/memcpy/munmap/writev
would go away.  Note, however, that since you can only pass one fd to
sendfile at a time anyway, delaying the sending of a FILE bucket is pretty
pointless if you're going to send it out with sendfile later anyway.  What
would be better is to mmap the file and hang onto the mmap to pass a bunch
of mmap'ed regions to writev() all at once.  For cache purposes, that just
means that all you have to do is consider the size of the files you're
dealing with, and if they're small, use MMapFile instead of CacheFile.  If
we then got rid of the apr_bucket_read/apr_brigade_write in the
core_output_filter and just saved up a brigade instead, you'd be set.

--Cliff


Mime
View raw message