Comments on: Technical Problems With Page Caching http://blog.whatclinic.com/2009/10/technical-problems-with-page-caching.html Sharing Tech, Marketing & Health 2.0 information Sat, 11 Feb 2012 20:40:18 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: cars classified http://blog.whatclinic.com/2009/10/technical-problems-with-page-caching.html/comment-page-1#comment-2178 cars classified Mon, 23 Aug 2010 09:28:28 +0000 http://blog.revahealth.com/?p=652#comment-2178 Great article..This article takes a more technical viewpoint on the caching issues raised ...thanks for sharing the nice and valuable information.keep it up.its really nice blog.. Great article..This article takes a more technical viewpoint on the caching issues raised …thanks for sharing the nice and valuable information.keep it up.its really nice blog..

]]> By: Dave Roe http://blog.whatclinic.com/2009/10/technical-problems-with-page-caching.html/comment-page-1#comment-760 Dave Roe Thu, 15 Oct 2009 15:02:01 +0000 http://blog.revahealth.com/?p=652#comment-760 Thanks Ciaran, your dev team and ours probably face much the same issues a lot of the time. We also cache data for search results and clinic brochures in our server data cache - entirely separate to the page caching. We have in past done fragment caching of the pages for brochure and search pages. We moved away from this as full page caching is much faster overall. Of course, the duplication of data in the page cache is much larger. (The same individual results will appear on many thousands of pages). Also, we began to show data within the search results that were specific to the search - for instance when you search for /dentists/ireland/dental-implants, you get a sub-set of results that you would get for /dentists/ireland - cache each result (as a 'component' in asp-land) and the cache is much more efficient. But, we are now showing the price for the dental veneers in the individual results on the page, so that became less of an option. Worse, since we are a worldwide site, and we show prices in local currencies - we now have to cache the #results * #treatments * #currencies, and the number balloons. The full page cache has the same problems, but at least we're covering the most frequently requested pages and the speed is excelent when the page is in the cache. The downside (and we didn't go into this in the article), is that while we can invalidate the indivdual entries in the data cache, we cannot invalidate pages in the page cache - the server hides that from us. Apparently IIS7 will allow us more control, an upgrade we're increasingly considering. Of course, as you point out, that really lets the snakes out of the box, but the upside is that a user who updates their details can see the results of the change immediatley, as we will invalidate cache on an update. Thanks for your feedback! Thanks Ciaran, your dev team and ours probably face much the same issues a lot of the time.

We also cache data for search results and clinic brochures in our server data cache – entirely separate to the page caching.

We have in past done fragment caching of the pages for brochure and search pages. We moved away from this as full page caching is much faster overall. Of course, the duplication of data in the page cache is much larger. (The same individual results will appear on many thousands of pages). Also, we began to show data within the search results that were specific to the search –
for instance when you search for /dentists/ireland/dental-implants, you get a sub-set of results that you would get for /dentists/ireland – cache each result (as a ‘component’ in asp-land) and the cache is much more efficient. But, we are now showing the price for the dental veneers in the individual results on the page, so that became less of an option. Worse, since we are a worldwide site, and we show prices in local currencies – we now have to cache the
#results * #treatments * #currencies, and the number balloons. The full page cache has the same problems, but at least we’re covering the most frequently requested pages and the speed is excelent when the page is in the cache.

The downside (and we didn’t go into this in the article), is that while we can invalidate the indivdual entries in the data cache, we cannot invalidate pages in the page cache – the server hides that from us. Apparently IIS7 will allow us more control, an upgrade we’re increasingly considering.

Of course, as you point out, that really lets the snakes out of the box, but the upside is that a user who updates their details can see the results of the change immediatley, as we will invalidate cache on an update.

Thanks for your feedback!

]]> By: Ciaran Lee http://blog.whatclinic.com/2009/10/technical-problems-with-page-caching.html/comment-page-1#comment-759 Ciaran Lee Thu, 15 Oct 2009 13:10:27 +0000 http://blog.revahealth.com/?p=652#comment-759 RateMyArea is a rails app, and while the tools we use are different, many of the issues are the same. We employ action (similar to page caching but slightly slower) and fragment caching, as well as storing the results of some expensive SQL statements in our memcached store. We are lucky in that our pages and fragments can be cached indefinitely, until an action happens that invalidates them, so there are no ttl issues (although cache invalidation is hard!) RateMyArea is a rails app, and while the tools we use are different, many of the issues are the same.

We employ action (similar to page caching but slightly slower) and fragment caching, as well as storing the results of some expensive SQL statements in our memcached store.

We are lucky in that our pages and fragments can be cached indefinitely, until an action happens that invalidates them, so there are no ttl issues (although cache invalidation is hard!)

]]>