Linus Torvalds wrote:
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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html