On Sat, 03 Jan 2004 14:43:02 -0800, Brion Vibber wrote:
Hi Brion,
thanks for this in-depth explanation!
I'll add some comments regarding a possible squid integration:
Then the database is queried to see if the page exists
and whether it's
a redirect, and to get the last-touched timestamp.
If the client sent an If-Modified-Since header, we compare the given
time against the last-touched timestamp (which is updated for cases
where link rendering would change as well as direct edits).
Ah- so this would be the point to hook in for downstream cache
invalidation (PURGE requests). Great news, then the timeout for anonymous
views could be really high on the squids, practically static serving.
Reallly fast...
if the browser doesn't advertise understanding
gzip, we
decompress it on the fly. (Note that this may affect benchmarks in
comparison to actual browsers in use, I don't know.)
Squid would cache both the compressed and the decompressed page- Vary:
Accept-Encoding, Cookie does this. It will most propably cache two or
three variants of the Accept-Encoding value (Browsers differ in what they
advertise).
A global cache epoch can be set on the server
to invalidate all old cached pages (server
This would need a call to a wildcard purge for all languages.
and
individual user accounts also have a cache epoch which is reset on
login, when user options are changed, and when talk page notification
comes on/off.
No squid caching here, no action.
If this is a redirect, old page view, diff, or
printable view,
All these could most propably be cached as well. Squid caches the headers
as well, so the redirect does what it's supposed to do. The printable view
would need to be purged with the page, the others propably never change,
i'm not shure.
Ideally we'd be putting cached data into
memcached, which can run
in-memory on the web server (or as a distributed cache over a web server
cluster) without grinding down the disks. So far we use memcached just
for some common data (localized messages, utf8 translation tables,
interwiki prefix lookup) and login sessions.
Squid uses a freely configurable memcache (config options include size,
max object size, different replacement algolorithms) by default- the
bigger, the better for the disk and the better the speed of course.
What is the reason for sending a session cookie for anonymous users? User
tracking? This collides with downstream caching (Vary: Cookie), so if this
could be switched off the only issue would be solved.
Gabriel Wicke