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