Linus Torvalds wrote:
quoted text
> 
> On Fri, 8 Dec 2006, Jeff Garzik wrote:
>> This is a bit cheesy, and completely untested, but since mod_cache never
>> worked for me either, I bet it works better ;-)
> 
> Ok, this doesn't do the locking either, so on cache misses or expiry, 
> you're still going to be that thundering herd.

Well, gdbm does reader/write locking.

You still bit a bit of a thundering herd, though.  I suppose I could 
open the gdbm db for writing before calling the CGI, which would 
effectively get what you're looking for.


quoted text
> Also, if you want to be nice to clients, I'd seriously suggest that when 
> you hit in the cache, but it's expired (or it's close to expired), you 
> still serve the cached data back, but you set up a thread in the 
> background (with some maximum number of active threads, of course!) that 
> refreshes the cached entry and then you extend the expiration time so that 
> you won't end up doing this "refresh" _again_.
> 
> It's kind of silly to have people wait for 20 seconds just because a cache 
> expired five seconds ago. Much nicer to say "ok, we allow a certain 
> grace-period during which we'll do the real lookup, but to make things 
> _look_ really responsive, we still use the old cached value".

True, should work with gitweb data at least.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html