On 09/09/14 22:00, Daniel Kinzler wrote:
Sadly, the mechanism for determining the parser cache key is quite complicated and rather opaque.
It's only as complicated as it has to be, to support the desired features:
* Options which change the parser output. * Merging of parser output objects when a given option does not affect the output for a given input text, even though it may affect the output other inputs.
The approach Katie tries in I1a11b200f0c looks fine at a glance, but even if i can verify that it works as expected on my machine, I have no idea how it will behave on the more strange wikis on the live cluster.
It will probably work. It assumes that the parser output for the current article will always be added to the OutputPage before the SidebarBeforeOutput hook is called. If that assumption was violated on some popular URL, then it could waste quite a lot of CPU time.
It also assumes that the context page is always the same as the page which was parsed and added to the OutputPage -- another assumption which could have nasty consequences if it is violated.
I think it is fine to just invalidate all pages on the wiki. This can be done by deploying the parser change, then progressively increasing $wgCacheEpoch over the course of a week or two, until it is higher than the change deployment time. If you increase $wgCacheEpoch too fast, then you will get an overload.
-- Tim Starling