A core issue for modern websites is one of cache invalidation. The linked article essentially sidesteps the issue, with the in-memory speed of memcache obscuring the problem.
For traditional LAMP-style document-producing engines, cache invalidation strategies rely either on TTL (leading, as he says, to stale data) or on polling the source data (leading to an unavoidable performance hit, amortised over the improved speed of the cache).
Leaving aside TTLs, the key issue is that cache invalidation is driven by GET and not POST requests. I wrote a thesis proposal where part of the concept was to drive all cache invalidation from POSTs. New comment added to a story? A regeneration is queued up. New post on front page? A regeneration is queued up.
Firstly, you can improve both staleness by only regenerating when new data is added, and you improve performance by not needing to poll the source data for currency every time you touch the cache. In an ideal situation you could come close to raw HTTP serving speed.
You also allow some degree of dynamic responses to load. Under high rates of POSTs you can batch up regeneration events to prioritise the GETs.
However, I won't be pursuing that project -- I've been accepted for one I was more interested in.
For those interested in full page caching, smart cache invalidation & and a built in crawler. Check out Drupal's boost module. http://drupal.org/project/boost
I'm the guy who has shaped this into the monster it has now become. The apache htaccess rules are still getting refined & it comes with lighttpd and nginx rules as well.
I've been working on taking this full circle; taking the monster that was created, keeping the core parts that work and spiting the other parts into separate Drupal modules.
http://drupal.org/project/expire will contain the cache invalidation logic and I'll create a crawler once I come up with a better multi process crawler http://groups.drupal.org/node/126624
I think the reason that cache invalidation scheme is not in wider use is that it's not very generalizable, and as data model complexity increases things get out of control. If someone adds a new post, you may end up having to regenerate the post page, the pages before it and after it, an authors page, any number of tags pages, etc. So I think it works sometimes in specific instances, but not as a general caching strategy.
If it worked though, it would seem to be the most beneficial. Is anybody working on it?
I've been thinking along similar lines for my project and the issue i'm running into conceptually is tracking WHICH cache records to invalidate upon POST. Say an HTML list, an HTML detail page, and a full composite object all contain references to the particular item you updated. Single items - the detail page and object are fairly easy to know about, but what about a list view and a grid view that also contain that item. What are your thoughts?
A dependency graph between database tables and pages, no? How to define 'page' depends on the rest of the application, I guess in most frameworks it would be 'module' + 'action'.
Seeing as nginx requests can be done by their URI, you could have a /write prefix to anything that handles user input, which wouldn't be cached? Especially on sites that don't have masses of user writing (in which case you'd use some sort of intermediary queueing daemon that nginx could shove things to, and could slowly feed the things into your backend).
Writing the /write prefix would immediately invalidate the cache for the changed pages and thus they could be easily regenerated a single time and placed into the cache until the next time (or perhaps the pages could simply be invalidated once every 10 seconds or so - very little has to be truly realtime).
Yes, this is what I thought he was saying, but I was thrown off by his 'I think this is entirely new' comment in the beginning. Pre-generating pages when the data changes is not new, we did it in 2000. Maybe I didn't fully understand and there is some aspect of it that is new (for example we used disk-based caches, not memory, but that doesn't really change the idea imo).
For traditional LAMP-style document-producing engines, cache invalidation strategies rely either on TTL (leading, as he says, to stale data) or on polling the source data (leading to an unavoidable performance hit, amortised over the improved speed of the cache).
Leaving aside TTLs, the key issue is that cache invalidation is driven by GET and not POST requests. I wrote a thesis proposal where part of the concept was to drive all cache invalidation from POSTs. New comment added to a story? A regeneration is queued up. New post on front page? A regeneration is queued up.
Firstly, you can improve both staleness by only regenerating when new data is added, and you improve performance by not needing to poll the source data for currency every time you touch the cache. In an ideal situation you could come close to raw HTTP serving speed.
You also allow some degree of dynamic responses to load. Under high rates of POSTs you can batch up regeneration events to prioritise the GETs.
However, I won't be pursuing that project -- I've been accepted for one I was more interested in.