Comments on: Aggressive Caching With Memcached http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/ On Databases, Recovery, Tech Mon, 06 Sep 2010 10:04:38 +0000 http://wordpress.org/?v=2.2.1 By: mrkris http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-2052 mrkris Sun, 07 Dec 2008 18:12:54 +0000 http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-2052 @admin Yeah, there are many methods of caching. DB query, action caching, page caching, fragment caching. Heck, you could make page caching (full) dynamic by using js. Many methods to choose from :) @admin Yeah, there are many methods of caching. DB query, action caching, page caching, fragment caching. Heck, you could make page caching (full) dynamic by using js.

Many methods to choose from :)

]]> By: admin http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-1953 admin Thu, 27 Nov 2008 18:15:19 +0000 http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-1953 @mrkris You certainly can get better performance that way. With this method, you pretty much max out at 1000-1500 requests/second. Your method would probably add an extra 500-1500 requests/second on top of that. There are cases where your method wouldn't work, though. For instance, if you're aggressively caching for users who aren't logged in, but only caching database objects for users who are logged in. They all have their own advantages and disadvantages. @mrkris

You certainly can get better performance that way. With this method, you pretty much max out at 1000-1500 requests/second. Your method would probably add an extra 500-1500 requests/second on top of that.

There are cases where your method wouldn’t work, though. For instance, if you’re aggressively caching for users who aren’t logged in, but only caching database objects for users who are logged in.

They all have their own advantages and disadvantages.

]]> By: mrkris http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-1952 mrkris Thu, 27 Nov 2008 17:54:41 +0000 http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-1952 Some would disagree, but my caching generates the full path to the requested file and caches that on the filesystem, that way once the page is cached, rewrite will force apache to hit that before hitting php -- serve your pages as fast as apache/etc can send it. Some would disagree, but my caching generates the full path to the requested file and caches that on the filesystem, that way once the page is cached, rewrite will force apache to hit that before hitting php — serve your pages as fast as apache/etc can send it.

]]> By: Erik Ljungstrom http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-602 Erik Ljungstrom Sun, 24 Aug 2008 20:18:42 +0000 http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-602 There are far more efficient techniques for output caching than hitting memcached (as efficient as it may be). Varnish is a good bet! But I also agree with Ian, object caching is often very beneficial and works just fine in combination. There are far more efficient techniques for output caching than hitting memcached (as efficient as it may be). Varnish is a good bet! But I also agree with Ian, object caching is often very beneficial and works just fine in combination.

]]> By: Ian Eure http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-545 Ian Eure Sun, 17 Aug 2008 20:47:24 +0000 http://blog.charcoalphile.com/2008/08/17/aggressive-caching-with-memcached/#comment-545 As you scale up, this approach doesn't work as well. You end up needing something like a NetScaler, which handles load-balancing and caching. Depending on your traffic rates, you can enable output caching for anonymous users only and see significant benefits. You will also see improvement if you cache your data, rather than doing output caching. This shifts the load off the database, at the cost of a little more processing in your app code. You have enough flexibility that you can cache complex data and filter it down fairly easily in your application. For example, you may cache every action by all users on the site, then fetch them and only show ones for the user being viewed. You’re just a step away from explicit dirtying, which is a good goal. You just keep your data in the cache forever, and remove (or better yet, update) it when needed. With that layout, you basically never have to worry about populating it, and it’s a step towards decoupling things further, putting the DB query / cache logic into a completely different system than the cache fetch / display logic. As you scale up, this approach doesn’t work as well. You end up needing something like a NetScaler, which handles load-balancing and caching.

Depending on your traffic rates, you can enable output caching for anonymous users only and see significant benefits.

You will also see improvement if you cache your data, rather than doing output caching. This shifts the load off the database, at the cost of a little more processing in your app code. You have enough flexibility that you can cache complex data and filter it down fairly easily in your application. For example, you may cache every action by all users on the site, then fetch them and only show ones for the user being viewed.

You’re just a step away from explicit dirtying, which is a good goal. You just keep your data in the cache forever, and remove (or better yet, update) it when needed. With that layout, you basically never have to worry about populating it, and it’s a step towards decoupling things further, putting the DB query / cache logic into a completely different system than the cache fetch / display logic.

]]>