https://bugzilla.wikimedia.org/show_bug.cgi?id=44570
--- Comment #32 from Tim Starling <[email protected]> --- (In reply to comment #28) > (In reply to comment #27) > > We have been running /usr/local/bin/mwscript purgeParserCache.php with > --age=2592000 for a couple months now (see r38275), did you not agree with > this? Should we be changing it? I've reviewed the hit rate data on graphite. From the perspective of parser cache hit rate, the expiry time should probably be 2-3 months, but judging by the time between parser resets, we can't store much more than 1 month without running out of disk space. In February 2012, we had an absent rate of only 2%, with an expired rate of 5%, after 6 months of fill time. We never achieved anything like that again, apparently because of disk space constraints. But with 1 month we should see something like 7% absent plus 2% expired. At least it's a big improvement over http://tstarling.com/stuff/hit-rate-2011-03-25.png Some data I gathered before the start of the MySQL parser cache project. I don't think it's appropriate to set the parser cache expiry time based on the number of MW instances we can store on the cluster. The CPU cost of rewriting the bits URLs would be negligible compared to the CPU cost of reparsing the article from scratch. We don't want to have to increase our deployment period just to achieve a higher hit rate, and we don't want the deployment period to affect how much disk space we buy for the parser cache. There are plenty of ways to decouple the two. Ultimately, I'd like to use an LRU expiry policy for the parser cache, instead of deleting objects based on creation time. That will make a decoupling between expiry time and MW deployment cycle even more necessary. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
