Scott Hanselman's Computer Zen - The ASP.NET Cache object in a Web Gardening scenario with IIS5 or IIS6

First time here? Check out the site's "greatest hits" or read a post from the archives. Feel free to leave a comment or ask a question, and consider subscribing to the latest posts via RSS or e-mail. Thanks for visiting!

« Nantpad: The Good and the Bad of it | Main | Dietary and Nutritional Information for ... »

The ASP.NET Cache object in a Web Gardening scenario with IIS5 or IIS6

Posted in ASP.NET.

Remember that "Web Gardening" is like having a tiny Web Farm on a multi-proc box. Each processor gets an ASP.NET Worker Process with affinity (that means the process "sticks") to that processor.

But what happens if you use the Cache object? Well, each AppDomain gets a Cache object, and each ASP.NET Worker Process has one AppDomain per Web Site, and each processor gets one WP, so...if you have four processors, the Cache object will exist four times.

That means, ASP.NET Cache state is NOT shared amongst processors in a single-box multi-proc system.

Make sure you grok this if you ever find yourself working on a single box web site with multiple procs and web gardening on. If you've:

coded your site to assume that the cache will fill once and only once per machine
used physical files as CacheDependancies to key off the cache
assumed that any one user will magically return to the same process on the same machine on subsequent requests

then things may well behave differently than you thinkin a web gardening scenario.

Posted at 2004-08-17 08:34 PM by Scott
Comments [3]
Permalink

Wednesday, August 18, 2004 1:22:59 AM (Pacific Standard Time, UTC-08:00)

Well put, I blogged something similar, but yours is much more eloquently put.

I did remark that the setting for this is far to simple, that there was no warning or description to its effects, but then one could argue that if your messing in those settings you best know what your doing.

http://blog.binaryjam.com/simon/archive/2004/05/14/159.aspx

SimonT

Wednesday, August 18, 2004 7:55:30 AM (Pacific Standard Time, UTC-08:00)

I think another big "gotcha" to point out:

When working with cache, you should never assume the data is available in cache (it can expire before your expirate time), so you must always check before using it. If not available, then retrieve it from the source. So a good way to make sure the cache is updated when your app makes a change to the underlying data source is to remove the item from cache when the change is made.

However, if you programmatically remove an item from cache (so that updated data is retrieved from the source on it's next request), don't assume it will be removed from EVERY instance.