If you aren't using caching in your code you are missing out. I wrote a little article with some examples of how to easily use caching within your code. If you are on a shared hosting account this can make a huge difference in speed. Check it out.
http://blog.whitesites.com/Using-Caching-to-make-your-ASP.NET-website-more-scalable__633475786261472087_blog.htm

On that same note you really have to be careful of what you're caching and why. Especially in a shared hosting environment. Caching can be extremely memory intensive if it's not being used and/or managed properly. It may speed up your sites if only you (and maybe a handful of other customers on the box) are caching your site(s), but if every website decided to utilize caching it'd probably bring the server to it's knees in record time.

Couple that memory usage with bad programming (because we all either make mistakes or know half-assed programmers) and now this shared hosting environment is a nightmare.

I'm not saying that caching doesn't have it's place, but I'd be more apt to cache entire page outputs for 10-to-30 seconds than to cache application objects (DataSets, DataTables, etc) for obvious reasons... most notable page output being a helluva lot smaller (and even faster to be honest) than just tiny bits and pieces of application logic throughout the app.

Anway just my $.02.

I agree with you on the larger objects such as Datasets and DataTables, but I would advise against page outputs for any amount of time. It takes a good amount of memory to cache an entire page. This is why I am sticking to smaller objects. I also am only caching strings, not bitmaps or other objects.

Using these techniques the memory footprint is very small ( 4.2K for over 20 items ) I am only caching objects that almost never need updating ( categories list, authors list, titles and keywords ). I also have a function on my backend that allows me to clear the entire cache if I do make an update to a given cached section.

Even though caching an entire page is easier, it could quickly take a large chunk of memory on some dynamic website. Why do you think it would be faster than just caching smaller objects?

Don't get me wrong. I agree with you that caching datasets is going to speed up the site/pages alot, especially in an environment where the database server resides on a different physical server elsewhere in the network.

But Caching just small objects means that ASP.NET still needs to process every other part of the application logic in that page.

We can get around this, however, if we cache entire page outputs (basically ASP.NET holds onto the generated HTML for the caching period) then we're not hitting the server at all besides a request and response. Yes, ASP.NET still has to handle the request, but it doesn't need to execute the application logic while the cache hasn't expired.

P.S. Just for clarification I'm talking about using the OutputCache directive.

Hey Josh,
I understand what you mean by caching the entire page. Even though yes it is very fast ( as fast as it gets ). This requires that your server have a ton of memory. This might not be best best case senereo for Shared Servers, and small VPS boxes. If the site is small ( 20 of so pages ), and the content doesn't change very often, then yes what you suggesting with page caching is the best solution. But if you run a Social Networking community this gets a little more demanding. As every QueryString Combination would be a entirely new cached page.

for example one of my sites has 1200 members. If we cached every members page and all their photo sub pages this would be around 10,000 pages. Average page is 80K. This means we would need 800 Megs of ram just to cache all these pages. This doesn't include our event galleries or other pages.

Instead of caching entire pages, I feel its more efficient to cache elements that are reused on many pages. This promotes code reuse, and doesn't waste ram like page caching can on highly DB driven websites, that have to scale to the number of users.

Yes this might put a little more stress on the CPU than page caching, but it still a lot less work then forcing the application to building strings of HTML, and ping the DB over and over.

The last thing we want is to get every noobie .NET developer on a shared hosting account to cache the pages on their MySpace wanna be site.

Again, we're not talking about caching pages for long. On a high traffic site I would say no MORE than 10 seconds with 5 or 6 seconds being ideal. On lower traffic sites you could get away with more time.

Ideally a page's HTML output should be next to nothing in most instances.

But for now I guess that I'll agree to disagree.



Or caching much of anything on any size website to be quite honest. I've seen poor developers storing whole recordsets (among other things) of poorly optimized/requested data (SELECT *'s with no WHERE, GROUP BY, LIMIT, etc clauses for instance - causing the entire table to be returned, or using multiple/many DB requests instead of using a UNION or JOIN) in memory for very long times... sometimes it was using a cache object, other times it was using SESSION.

In any regard, unless you REALLY know what you're doing it and why you're doing it caching can be a great asset or a great detriment.

I think we both agree that using the cache is great, but only if used properly.
Page caching is great if it servers the right purpose. Most of the sites I work on are too dynamic, and I couldn't get away with page caching. ( even for a few seconds ).

I am caching my objects for 12 hours. Granted these objects are not time sensitive meaning their content is not dependant on a DateTime. Example if I have a articles that I don't want to display until a certain time this would be an object depending on the Server's DateTime. These objects I don't cache. Just objects that are reused over and over again. I would think that the longer you can keep an object in cache the better it would be for high traffic websites.

Yes I agree with you. It all depends on proper use of the cache. Honestly it took getting a 256 windows VPS for me a realize how much memory I really had at my disposal. I think a lot of guys on shared hosting accounts live in some fantasy land about how much memory they have at their disposal. I would never use the cache for datasets. Just for Stringing together some HTML that is to be fed into place holders.

Something that I have found interesting is if you go over your memory allocation on your VPS this will corrupt your cache, and cause your entire site to go down. When this happends I have to login and recycle the application pool.

I need to make a backdoor to my website so I could recycle the App Pool from my cell phone ( via text, email, web , something )

Just make sure you run this little tool from a different site/application pool

yeah that would be counter productive.