How Caching Means More Ca-ching, Part 1 - Fragment Caching
(Page 4 of 4 )
Careful how you read this one, it's not Fraggle Rock caching, though that would be extremely cool! "Hide you cares away, worries for another day...". This is fragment caching, and the name basically explains everything about it. We are essentially breaking up pages into chunks, or fragments, and setting the cache properties of those fragments individually. This is accomplished through the use of user controls.
I'll give you an example. Suppose you've built a time-sheets application. Most of the data could be very dynamic, perhaps people entering in full and half hours on different projects throughout the day. There may however be a schedule of people assigned to various tasks that doesn't change all that often. Well, instead of querying the database for the schedule with every page load, a potential speed booster would be to place the schedule generating code into a user control, and configure the output caching within the control itself. We've already learned how to do this, just set the @OutputCache directive or use the HttpCachePolicy class within the control, it's that easy.
One quick caveat: fragment caching doesn't support the VaryByHeader or VaryByCustom attributes. The VaryByParam works the same as with output caching, and in addition we have the use of another attribute, VaryByControl. This enables us to vary the cached output, based upon the values of server controls contained within, such as a select box, or check boxes. I won't go through the process of a user control tutorial, but you should be able to find what you need in this nice article by JB Reddy.
Aside from just giving us one awesome degree of flexibility within pages to cache or not cache whichever chunks we deem necessary, there is one other very cool advantage to fragment caching. Suppose you have a fairly common user control, for example: a navigational menu system that is shared throughout most if not all pages in the application. Well, you can set the output caching on that one fragment, that one user control, and enjoy the increase in performance instantly throughout all pages. Happy now?
Conclusion
There are many advantages attained when caching is utilized properly within an application. First of all, it's easier on the server's memory resources if you determine that fragment caching is appropriate in place of output caching. It makes for faster page loading, as script processing and database querying is only needed once for the allotted cache time, and from there on in the page can be quickly, yes, very quickly served up from memory.
If you wish to see what kind of a difference can truly be achieved, build your application first. Do some benchmarking. Then implement caching. (Keep in mind that the next article will cover yet another method, but these two should get you off the ground) You should notice improvements in the range of several hundred percent faster page loads.
So why caching mean more ca-ching? Well, remember Jack (mentioned in the outset). The users find his application too slow, and it was be nothing but complaints, despite how feature-rich it was. Jack realized that the faster you can allow people to do what they have to do, the more endeared they will be to your application, so he planned and implemented caching. Praise came showering his way, as well as good recognition. I'm sure you can connect the dots as to how that eventually lead to more ca-ching.
| 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. |
/ 28 
