2010/10/6 Rob Lanphier <robla(a)wikimedia.org>rg>:
Priyanka is the dev working on this, and the strategy
she is pursuing
now is to switch from immediately parsing the later revision, and
instead calling the API to get a parsed version of the latest
revision. What that means is that we can display the diff
immediately, and then inject the diff via Javascript.
Presumably you mean to inject the /parsed contents/ with JS?
In talking to Sam this morning about this, a couple
things became clear:
1. This requires action=parse, which is already on the list of APIs
that generate healthy load
For parser cache misses, yes. From you post I understand
that you'd
only be doing this for parser cache misses, correct?
2. While this move should be net-neutral in CPU load,
it does shift
the load from general purpose Apaches to the API servers, the latter
of which are more heavily loaded
That could cause problems, depending on the volume. If we (and by that
I mean Mark, CCed) are prepared so we can move Apaches from the
general cluster to the API cluster relatively quickly, I think we
should be able to rebalance the load that way.
Additionally, it's theoretically possible that
this will actually
generate more load, since it'll be easier for people to skim the
history, unintentionally generating lots of (never completed) API
calls.
This is the greater of my worries. Would it be terribly intrusive to
only load the parsed page upon user interaction (e.g. using a link or
button) by default, possibly with a user preference to always load it?
Roan Kattouw (Catrope)