Tim Starling wrote:
In the cur table, there is a field called
"cur_touched". This field is
used for cache invalidation. If links on the page change from broken to
unbroken or vice versa, cur_touched is set to the present. This field is
queried to determine whether the client cache or the parser cache is valid.
I see. If we are okay with sacrificing a few 304 Not Modifieds, I have
an idea of an alternative scheme that can work without having to modify
cur_touched of hundreds of pages when a template is changed.
I think we should have an equivalent of what is cur_touched in memcached
(I'll call it a touched-key), and if it is not in memcached, the page is
served.
This means that sometimes such a touched-key will expire from the cache
and *one* page will be served instead of 304ed, but more importantly,
editing a template (or, in fact, creating a heavily-linked-to page)
would require only purging (parser cache (memcached) and squids), and no
database queries on hundreds of rows.
You can't store anything in memcached unless
you're prepared to have it
go missing.
Oh, come on, I know that. :) I don't think the few times that a
touched-key "goes missing" are that much of a problem. Compared to fully
parsed pages, the touched-keys are extremely small, and hence many of
them can stay in memcached. If one does go missing, then we'll just have
to serve the page; if we're lucky, it's still in the parser cache. If
not, then we re-render it, but we also update both the parser cache and
the touched-key.
Memcached is appropriate for caching read operations,
but
not for replacing write operations.
cur_touched is not the kind of information that is essential to keep
(meaning: it is not a problem if this information "goes missing").
Timwi