On Sat, Jul 31, 2010 at 1:45 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Fri, Jul 30, 2010 at 4:49 AM, John Vandenberg jayvdb@gmail.com wrote:
Could we add a logged-in-reader mode, for people who are infrequent contributors but wish to be logged in for the prefs.
...
Fortunately, the major slowdown is parser cache misses, not Squid cache misses. To avoid parser cache misses, just make sure you don't change parser-affecting preferences to non-default values. (We don't say which these are, of course . . .)
So you're telling my theoretical logged-in-reader to use default prefs, or log out, when the reason they are a logged-in-reader is so they can control their preferences..!
They could be served a slightly old cached version of the page when one is available for their prefs. e.g. if the cached version is less than a minute old.
That would make no difference. If you've fiddled with your preferences nontrivially, there's a good chance that not a single other user has the exact same preferences, so you'll only hit the parser cache if you yourself have viewed the page recently. For instance, if you set your stub threshold to 357 bytes, you'll never hit anyone else's cache (unless someone else has that exact stub threshold). Even if you just fiddle with on/off options, there are several, and the number of combinations is exponential.
Someone who sets their stub threshold to 357 is their own performance enemy.
Surely there are a few common 'preference sets' which large numbers of readers use?
How many people only look at the front page in the morning, and jump to a few pages from there..?
Moreover, practically no page changes anywhere close to once per minute. If the threshold is set that low, you'll essentially never get extra parser cache hits. On the other hand, extra infrastructure will be needed to keep around stale parser cache entries, so it's a clear overall loss.
There are plenty of pages which change more than once per minute, however I'd expect a much higher threshold, variable based on the volume of page activity, or some other mechanism to determine whether the cached version is acceptably stale for the logged-in-reader.
There is no infrastructure required for extra stale entries. If the viewer is happy to accept the slightly stale revision for there chosen prefs, serve it. If not, reparse.
The down side is that if they see an error, it may already be fixed. OTOH, if the page is being revised frequently, the same is likely to happen anyway. The text could be stale before it hits the wire due to parsing delay.
However, in that case everyone will see the new contents at more or less the same time -- it won't be inconsistent.
Not on frequently changing pages. many edits can occur while I am pulling the page down the wire. I then need to read the page to find this error.
-- John Vandenberg