MemCached Client for CFMX - alpha version

Very cool stuff. Surprisingly easy to implement in CF!

Not entirely sure why "each server having duplicate copies of the cached data" is a bad thing, since the primary reason for caching data locally is speed. For example, practicaly every element that appears on a Yahoo home page is pre-rendered and cached locally on each server.

That's why it can deliver extremely complex personalized pages quickly, since fundamentally it's grabbing a block here and a block there, stacking 'em all together, and pushing the result out the door.

It would seem that judicious use of ram and file-based caching would beat this out for speed, especially if you have a significant number of cached items per page, each of which need a separate HTTP request.

Mark - Agree about updating being a pain, as that typically means that I need to be a little more conservative in regard to cache periods than I'd really like. But even an expiration period as short as five minutes can still be a major improvement on something like a home page. Or you can do as I did, and setup up a private page that simply rebroadcasts any query string parameters to stub pages on all known servers.

http://myserver.com/private/bc.cfm?sc=12345&ca...

(SC is a security code used to prevent anyone from using the page as a DOS attack vector.)

As such, I don't consider multiple-copies being wasteful. Any place large enough to need a dedicated content caching server isn't going blanch over provisioning a web server with an extra gig or two of ram. Performance-wise you can't beat it. And scalability-wise, you don't have single-point-of-failure issues when the caching server goes belly up.

That said, I do like the possibilites inherent in the technique.

If a CFApp instance is going to be problematic then--since it's running your web application--you're going to be dealing with a few issues anyway (grin).

And if I reframe your question you'll see it kind of answers itself: how would you, using a caching server, perform cache invalidation? If I can send a memcache server a key to invalidate (say, an article UUID), then I can probably also broadcast the same key to invalidate.

As to caching, I typically do three types: cfquery caches; caches of instantiated objects, ORM definitions, etc, which need to be present and are not good candidates for serialization; and completely rendered HTML at the view/page level (sidebar items, navigation items, home page content, landing page content, etc.).

The later is the most significant, since for the most part I don't see the point in caching all of the data to do the rendering, and still needing to do the looping and code needed to render it. I'd much prefer to skip that work and cache the final output (all where appropriate, of course). You want sidebar XYZ? Here it is: plop.

Again, I think the technique is cool, and applicable to other areas. I was simply pointing out that the advantage of centralized caching is counter-balanced by the disadvantage of centralized caching. If one of my servers with distributed caching goes down, the other servers LB and pickup the slack. If a single centralized server goes down... then we have issues.

Obviously, you could setup an application cluster to minimize the side effects of THAT scenario, but that makes the resulting solution even more expensive to implement and maintain.

Anyway, all of this doesn't mean people shouldn't do it. Doesn't mean they can't. Just means they need to weigh the pros and cons and make the right decision.

The work you're doing here is very important. I hope you make this production ready and can ensure that it works with query objects- that's the thing I need really really bad. memcached queries within cfmx.

Thanks,
Jon