httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: mod_cache: store_body() bites off more than it can chew
Date Fri, 03 Sep 2010 14:58:21 GMT
On 03 Sep 2010, at 4:25 PM, Niklas Edmundsson wrote:

> This could even go a bit further with providing the cache  
> implementation with a hint of when it would be polite of it to  
> return. I think it would probably be easier if the cache  
> implementation knows what's expected of it. Or?

That I've covered separately in the email about atomic commits.

> Also, if the client hangs up, will the cache impl get the chance to  
> finish its job (ie. completing the caching of a file instead of  
> starting over later on)?

That is a decision made by mod_cache itself, not the implementation  
though, but it's definitely possible. In theory, if mod_cache kept  
track of a downstream failure, and then responded to the failure by  
reading from the backend and caching until done before returning the  
error, this would definitely work.

> A side-step from this, how would it interact with the thundering  
> herd lock and slow client first to access large file while other  
> fast clients also wants to access it? Wouldn't this just be another  
> variety of the "client gets bored before reply" scenario?

The thundering herd lock never holds back a client or makes a client  
wait. When the URL is completely uncached, the lock allows the first  
hit to start to cache, and passes all subsequent requests through  
without caching, in the process stopping the huge race that used to  
occur while many requests attempted to cache the same file over and  
over until at least one response was successfully completed. When the  
URL is already cached and has recently gone stale, the first hit is  
allowed to hit the backend and (hopefully) refresh the entry, while  
subsequent requests are served stale content with a Warning (as per  
the RFC). There is a safety valve on the lock in that the lock only  
lives for a few seconds, so if the request to the backend breaks, a  
new request to attempt to freshen the cache will be attempted in a few  
seconds time.

> Regarding the issue of the disk cache cramming the entire file into  
> memory/address space, an alternate solution could be that the cache  
> returns buckets pointing to the cached file, ie that the cache  
> consumed those pesky mmapped buckets. This way the cache could cache  
> the file rather quickly independent of the speed of the client, so  
> that the file caching is finished in a sane time so others can  
> benefit from it even though the cache-initiating request is running  
> at snail-speed...

Been keen to do this for a while, this would definitely solve the RAM  
problem, but wouldn't solve the time problem. Copying 4GB of data from  
a slow disk can easily take minutes, and when Blu-ray images start  
becoming common, the problem would get worse.

Regards,
Graham
--


Mime
View raw message