On Sat, Jul 31, 2010 at 1:45 AM, Aryeh Gregor
<Simetrical+wikilist(a)gmail.com> wrote:
On Fri, Jul 30, 2010 at 4:49 AM, John Vandenberg
<jayvdb(a)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