Last modified: 2012-11-17 03:04:39 UTC
A little background...[[Pending changes]] protection went through a trial stage a few years ago with mixed results. After the trial it went inactive for a while until a recent RfC brought it back. As far as we know, pending changes will go into use again on Dec 1, 2012. So the problem is, protecting a page with Pending Changes roughly doubles page loading times. We tested this out by copying a large article into a test area and using an online tool to record the loading times. (The test page is at http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Testing/Glass%E2%80%93Steagall_Act) Anyway, I'm not sure if this is a bug that can be fixed, or if it would require a re-write of the software, but I thought I'd make you aware of the issue.
TIL: "Pending changes" = enwiki-friendly name for FlaggedRevs. -.-
This is not really possible to avoid on a cache miss scenario, perhaps with the exception of wikis with FR_INCLUDES_CURRENT (luckily what enwiki uses). Otherwise both versions need to be parsed to tell if they are in sync fully (which is all cached).
How was this tested? Using action=purge? There will be an increase in the scenarios where there can be a parser cache miss, but I'm actually having a hard time seeing where a page needs to be parsed twice on view (on edit it can happen for logged-out users).
(In reply to comment #3) > How was this tested? Using action=purge? > > There will be an increase in the scenarios where there can be a parser cache > miss, but I'm actually having a hard time seeing where a page needs to be > parsed twice on view (on edit it can happen for logged-out users). Actually even on edit that won't need to parse twice since the user sees the current version after submission (which is cached in doEditUpdates).
Closed due to lack of information. I wonder if these figures are old. Some double-parse scenarios where removed when the pending template/file change detection code was rewritten quite a while ago.
