asp.net caching implementation for popular content

In the following code i want to achieve this: every time a user asks for a specific piece of content, i first check if I already got this content from the DB on the same day. If so - I shall return the cached content. If not - i first re-retrieve the content from the DB ,return it to the user and cache it for the next requests from this day, and so on .. What i want to know is if it is a good code practice for saving (a lot of ) DB time on popular content . (I care less about how the code example looks, as just made it up for this question and it's not going to be used as-is in my app ..)

the code example:

public class ContentCachingExample
{
    private static DateTime _lastRequestTime;
    private static MyContent _cachedContent;

    private static MyContent GetContent()
    {
        // compare dates - content will be re-retrieved from DB once a day.
        if (DateTime.Now.Date> _lastRequestTime.Date) 
        {
            _lastRequestTime = DateTime.Now;
            _cachedContent = GetContentFromDb();
        }
        return _cachedContent;
    }

    private static MyConte开发者_StackOverflow社区nt GetContentFromDb()
    {
        // get content from DB
    }

    public class MyContent
    {
        public string Property1 { get; set; }
        public int Property2 { get; set; }
    }
 }

Yes, DB caching is part of best practice and can make very large performance gains. If you rely on it too heavily you can end up with very dispirit performance, say after the IIS worker has just restarted compared to once it has been running an hour.

Remember to think about cache expiration, what if this popular content changes? How long before you uses see the new content? You get a lot of the performance boost for cache times a lot smaller then 24 hours, if you have a page view a second a cache time of 1 minute will save you 59 trips to the DB and mean if a page gets slashdoted you have a (small) chance of surviving.

If you are using MS-SQL there are ways to invalidate caches if a row or a table changes

You may also want to investergate output caching if you are using ASP.NET, this allows you to cache the result from a page or a control, based on the URL parameters. This allows you to save web server CPU as well as DB load with your caching.

try using System.Web.Cache

private MyContent GetContent(){
   MyContent content = Cache[GetContentCacheKey()];
   if(content == null) {
     content = GetContentFromDb();
     Cache.Add(GetContentCaceKey(), content, null, DateTime.Now.AddHours(1), 
          Cache.NoSlidingExpiration, CacheItemPriority.High, null);
   }
   return content;
}

What you are doing is a common pattern.

You should consider some of the libraries that exist, particularly if you ever need to fine-tune the caching mechanism.

David has mentioned System.Web.Cache

There is also Enterprise Library Caching Blocks

However, if you only need the current capabilities of your code, then what you have is fine.

This is known as premature optimisation. You're attempting to solve a problem that you (presumably) don't know exists.

This is often harmful. For example, if you are experiencing bad performance right now, it could be because you are constrained by memory: for example, running SQL Server and IIS on the same machine, and it's too much. In that case, the caching-DB-content strategy would not help, it would make things worse.

If the DB query in question takes a long time to retrieve (as measured directly by you, and confirmed that it's too long for the user to wait: you really must do these two steps), then you might consider something as you suggested. You will want to look into the ASP.NET Cache object, rather than reinvent it yourself, though. A quick google turns up this page http://msdn.microsoft.com/en-us/library/aa478965.aspx which might be a good starting point.

Unless you have a performance problem, don't attempt to solve it now. You can develop with things like this in mind - that's why you should develop apps with clear separation of concerns, modularity, tiered structure, service architecture etc: you could easily add a 'caching layer' later, if needed.