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