Talk:Memcached

[edit] Use the laziest method

Always use the laziest method. Let's take a quick peek at what you've got here for options.

1. Expiration time — Bad idea. Updates are now delayed, this is ugly. On the plus side you might get to relieve some load at this price.
2. Delete cached objects when they have to be updated — Creating or deleting page X modifies Y, Z, what links here for those, etc etc etc; not the greatest thing in the world to do all at once.
3. Include timestamps and work by those — Bingo. This is similar to (2).
4. Delete cache at a button press — Unautomated. Might as well bang rocks together to get sparks.

(1) is self-explanitory. We know it's a time-out thing, we know this introduces latency between changes and reflection. Ignore it.

(2) and (3) are actually the same deal; (3) is the lazy version. In (2) it appears that the philosophy is that if you change a page:

• You must invalidate its cache entry
• You must then find all "What Links Here" cache entries for newly linked or removed pages, and delete them
• If the page was created or deleted, you now have to find the page that links to it, and delete that too
• Categories pages must also be checked in the case of category changes
• Template changes are a nightmare

Whereas (3) follows the following method if you change a page:

• Update the timestamp on the cache entry
• Whenever a "What Links Here" is hit, check related objects in memcache for their timestamps; regenerate if one is newer
• "What Links Here" also needs to look for deleted pages
• Deleted and moved pages need to invalidate related "What Links Here"
• Created and deleted pages are just checked for existence (this could be memcached) and if that changes, the affected page is regenerated
• Objects vanishing from memcache have their on-disk state verified (existence, modification timestamp, both of which are in the database anyway)
• Template changes are timestamp-checked, if newer the page is regenerated

(3) turns out to be slightly more complex; but you don't have to megaspider on a change and start cleaning out the cache memory, which will lower the probability of an object being invalidated between any two selected changes. The object may be invalid and need regeneration; but if nobody's accessing it, we can wait. If we invalidate it AGAIN on top of that, we cost precisely 0 added effort to regenerate; we infact saved a wasted regeneration that would have happened with (2).

An interesting idea, when an invalidation actually happens, try using (1) for the unparsed source; that is, pull the database entry into memcached, set an expiration time a la (1), generate the new parsed XHTML output, and cache that in accordance with (3). If you actually need to do it again soon, you'll skip a database lookup; if not, it'll fall out of memcached.