httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: mod_cache CacheMaxStreamingBuffer
Date Thu, 12 Dec 2002 17:40:46 GMT

> When I added CacheMaxStreamingBuffer originally, I had two
> reasons for making it a separate directive:
>
>   1. As a separate directive, it could be disabled by default
>      to guarantee that the new functionality wouldn't break
>      anyone's existing mod_cache setup.
>         [I'm no longer worried about this issue, now that
>         the code has been in place for a while.]
>
>   2. There are some extreme cases where the maximum cacheable
>      object size could be too large a value for CacheMaxStreamingBuffer.
>      For example, if MCacheMaxObjectSize is 20MB, and your server
>      is servering a mix of 10MB static files and 30MB streamed
>      CGI responses with no content-length information, then each
>      CGI response will cause mod_cache to buffer 20MB of content
>      before giving up and freeing all that space.
>         [I am still worried about this issue.]
>
> I suppose we could eliminate my second concern by simply adding
> a note to the documentation that says, "don't use ridiculously
> large values for MCacheMaxObjectSize."  What do you think?

Documenting the issue might be sufficient.  If we do need a directive, then
perhaps default it to MCacheMaxObjectSize and  use the directive to lower the
streaming threshold to handle the pathological cases.

>
> If you move the stream buffering to the storage manager, does
> that mean that mod_disk_cache won't be able to cache streamed
> responses any more?  Or are you thinking of mirroring the current
> buffering logic with something that stores the pending content
> in the file rather than in-core?

I haven't looked at mod_disk_cache recently but I seem to recall that it already
handled streaming content.  If it doesn't, it should be a simple matter to fix
by streaming the content to disk as you suggest.

Bill


Mime
View raw message