Last modified: 2010-09-27 16:46:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T26124, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 24124 - Diff pages don't use cached version of parsed current revision
Diff pages don't use cached version of parsed current revision
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
1.17.x
All All
: Normal normal (vote)
: ---
Assigned To: Aaron Schulz
:
Depends on:
Blocks: 25289
  Show dependency treegraph
 
Reported: 2010-06-25 16:11 UTC by Rodan BURY
Modified: 2010-09-27 16:46 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rodan BURY 2010-06-25 16:11:21 UTC
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.
Comment 1 Aaron Schulz 2010-06-25 18:34:07 UTC
Is it actually any slower with PC off for the page?
Comment 2 Gurch 2010-06-30 11:25:55 UTC
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.
Comment 3 Gurch 2010-06-30 11:33:37 UTC
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).
Comment 4 Roan Kattouw 2010-06-30 11:52:31 UTC
(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.
Comment 5 Gurch 2010-06-30 12:16:53 UTC
(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.
Comment 6 Aaron Schulz 2010-07-02 04:01:21 UTC
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.
Comment 7 Chad H. 2010-07-08 17:05:42 UTC
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.
Comment 8 Tim Starling 2010-07-09 00:21:47 UTC
Fixed summary, the problem is with the diff page, not the diff itself.
Comment 9 Rob Lanphier (RobLa) 2010-07-19 23:55:43 UTC
Chad tells me that Tim deployed this to en.wikipedia.org on Friday, July 16.  It appears to be much quicker to me.
Comment 10 Waldir 2010-07-20 07:34:33 UTC
(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.
Comment 11 Waldir 2010-07-20 07:36:00 UTC
Ugh, piped links don't work here. Clickable link, for convenience: [[Wikipedia:Wikipedia Signpost/2010-07-19/Technology report]]
Comment 12 Rob Lanphier 2010-09-27 16:39:03 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links