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 --
