Page MenuHomePhabricator

Diff pages don't use cached version of parsed current revision
Closed, ResolvedPublic

Description

A lot of users complained about the long time the diffs need to load with the Pending Changes. So I tried to find out more infos using Firefox's Firebug add-on. Here is what I get:

As of now, when reading articles like "Alexander the Great" I get the normal behaviour (2-3 seconds to load the page).

But when I try view a diff, it's another story. There is only one issue: the first request for the diff (http://en.wikipedia.org/w/index.php?title=Alexander_the_Great&diff=369978513&oldid=369978381). It was only 82 Kb to download, and this request had to wait 18 seconds for the servers to begin sending the page. Once it started downloading, the download of the rest of the page began normally. All requests and elements on the page loads normally, with a total of 2 or 3 seconds.

There is a huge difference between the loading length of the article (3 seconds max) and it's diff (up to 21 seconds).

I'm not sure it's a pending changes issue though. I have the same issue on "London" for example. The first diff request had to wait 18 seconds, and was aborted. A new diff request was made, and I had to wait 30 seconds for the download to begin.

Anyway, one thing is certain: there is an issue with the diffs. You might want to download Firebug and try to reproduce.


Version: 1.17.x
Severity: normal

Details

Reference
bz24124

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:03 PM
bzimport set Reference to bz24124.

Is it actually any slower with PC off for the page?

matthew.britton wrote:

The speed of pretty much everything on Wikimedia sites peaked in early 2007 and has been getting gradually slower since then. (Much to my frustration -- I get endless complaints about how "this version of Huggle is so much slower than the last one" when I didn't even change any relevant code).

20 seconds is not only longer than the average user is prepared to wait for a response to a Web request, it's longer than they *can* wait if this stupid moderation system is to actually work.

matthew.britton wrote:

For reference, in 2007 a revert cycle usually took about 500 milliseconds ("pretty much instant" to a human). Obviously this wasn't helped by you guys relocating several thousand miles further away from me, but that does not account for the 5-10 seconds it now takes without the moderation system and ~30 seconds with it.

It's not like this is limited to diffs, either. If I'm logged in, it takes the best part of 30 seconds just to *view* moderately long articles like [[Barack Obama]]. (And 2 seconds when logged out, so the fault is at your end).

(In reply to comment #3)

For reference, in 2007 a revert cycle usually took about 500 milliseconds
("pretty much instant" to a human). Obviously this wasn't helped by you guys
relocating several thousand miles further away from me, but that does not
account for the 5-10 seconds it now takes without the moderation system and ~30
seconds with it.

The relocation is irrelevant here. The office was relocated from St. Petersburg, Florida to San Francisco, but the servers stayed in Tampa, Florida and remain there to this day.

matthew.britton wrote:

(In reply to comment #4)

The relocation is irrelevant here. The office was relocated from St.
Petersburg, Florida to San Francisco, but the servers stayed in Tampa, Florida
and remain there to this day.

Scratch that, then. Could have sworn response times took a hit right after the move, but must have been a coincidence.

Note the the preview of the output on diffs is *not* cached. Pages that take 17 sec to render will keep taking that much on diffs.

Should be fixed in trunk as of r69191. When diffing to the current revision (which is the most common scenario) we can use the parser cache to save some rendering time. In my test page (58,699 bytes), I was able to cut execution time from over 1100ms down to less than 15ms.

Fixed summary, the problem is with the diff page, not the diff itself.

Chad tells me that Tim deployed this to en.wikipedia.org on Friday, July 16. It appears to be much quicker to me.

(In reply to comment #7)

Should be fixed in trunk as of r69191.

For future reference, the revision that fixed the issue was (as reported by the [[Wikipedia:Wikipedia Signpost/2010-07-19/Technology report|Signpost]]) r69414.

Ugh, piped links don't work here. Clickable link, for convenience: [[Wikipedia:Wikipedia Signpost/2010-07-19/Technology report]]

Changing title to reflect that this problem isn't fixed in all cases, just in the case where the diff is against the current revision.