I see. We've got a large webmail installation here. Millions of users. All our backend web servers cache complex objects to a dedicated box with memcached, so we "spoil" cache on update as you say. And even if there's no dedicated cache box, I think it's worthwhile to at least try this strategy. In the case of current PM it will involve either propagating the "spoiling" to all neighbours via tcp/ip or storing the cache inside mysql database instead of web server RAM. I realize that these are big infrastructural changes and are hard to implement, though.
Also, I'd try to invest more time in increasing complexity of objects in the cache. Nodes seem to be "atoms" on PM. Too primitive and numerous to cache separately. There could be ways to cache whole threads with all nodes glued together to form a more high-level object. Nodelets are good candidates too. Do I make sense? I've implemented it for whole MIME structures and mailbox listings here in our webmail system. That payed off.
By "trying" I always mean "benchmarking a simple prototype" :)
P.S. The buttons on my calculator (old soviet Electronica) are ln, log and lg -- for natural, arbitrary and decimal logarithms, so perl (and C) log confuses me too.
In reply to Re^5: Randomization as a cache clearing mechanism
by kappa
in thread Randomization as a cache clearing mechanism
by demerphq
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |