How Caching Means More Ca-ching, Part 2 - Learn to Set Priorities!
(Page 4 of 4 )
If you accomplish your goal of becoming an advanced developer, and build wonderful applications to which people will instinctively flock like the salmon of Capistrano, you'll inevitably come up against certain limitations. One such limitation is the amount of available memory on the Web Server, generally something over which you have little control.
When this does happen (which it will), ASP.NET will try to shed some weight. It does this by purging cached items, which could present a problem if it were indiscriminately throwing items away, and something critical gets tossed. Naturally, Microsoft foresaw this situation, and graciously allowed us to set the Priority, or preferred purging order, of cached objects. Here are the different priority settings we have available:
- NotRemovable – Never removed on low memory purging. Be careful with this one!
- High – last purged
- AboveNormal – less likely purged
- Normal – default
- BelowNormal – more likely purged
- Low – first purged
Before I show you the code to implement this, I have to inform you that there are yet another two options that absolutely must be included if you wish to set cache priorities. The first is the CacheItemPriorityDecay setting, which decays (decreases) the priority as the object is less frequently accessed. It can be set to Never, Slow, Medium, or Fast.
The last option that must be set is the CacheItemRemoveCallback, which sets when the application is notified of the purging of a cached item. The possible settings are DependencyChanged, Expired, Removed, or Underused.
Here is the final example, showing all the options I've gone through:
strVal
= "Finally, we're done!"
cache.insert("item", strVal, nothing, datetime.maxvalue, _
timespan.fromseconds(60), CacheItemPriority.BelowNormal, _
CacheItemPriorityDecay.Fast, OnRemove)
Pros and Cons of Data Caching
To sum it all up, I'd like to just give a quick runs down of both the positive and negative aspects of Data caching.
On the positive side: if a page is too dynamic for either Output or Fragment caching, Data caching will provide the flexibility and performance enhancements that you require. Also, if you have very commonly accessed objects that may be used on several pages throughout your application, you could throw them in the cache so that they could be almost instantly delivered to each page from memory. And the biggest advantage I see is in the case of large or slow-loading objects. You can load them right into cache the first time they're requested, and continue to serve them from memory. This could be great for collections of data pulled from a database, such as an employee list, or a site navigation structure that you don't want to have to hit the database for on every page load.
So then, what are the negative aspects, the cons? Hmm, I would have to say that once you become adept at employing the various cache engines within your application, people will be too happy with you as a programmer, you will be far too much in demand, and your fame and pay-check will swell so greatly that you will be at risk of losing touch with reality. (Please write me if that happens to you.)
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 41 
