Roan Kattouw wrote:
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?
Yes.
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?
For consistency, it may also be done for all of them. I don't know which
one will they implement at the end.
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.
Shouldn't an incompelte api call abort the script?
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)
There's already a preference "don't show content below diffs", so once
content-less diffs get that link, the default could be changed (if diffs
are such a big issue, I don't know why it hasn't been already changed).