On Sat, Jul 31, 2010 at 1:45 AM, Aryeh Gregor <[email protected]> wrote: > On Fri, Jul 30, 2010 at 4:49 AM, John Vandenberg <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
