Hints for a high-traffic web service, c# asp.net sql2000

Question

I'm developing a web service whose methods will be called from a "dynamic banner" that will show a sort of queue of messages read from a sql server table.

The banner will have a heavy pressure in the home pages of high traffic sites; every time the banner will be loaded, it will call my web service, in order to obtain the new queue of messages.

Now: I don't want that all this traffic drives queries to the database every time the banner is loaded, so I'm thinking to use the asp.net cache (i.e. HttpRuntime.Cache[cacheKey]) to limit database accesses; I will try to have a cache refresh every minute or so.

Obviously I'll try have the messages as little as possible, to limit traffic.

But maybe there are other ways to deal with such a scenario; for example I could write the last version of the queue on the file system, and have the web service access that file; or something mixing the two approaches...

The solution is c# web service, asp.net 3.5, sql server 2000.

Any hint? Other approaches?

Thanks

Andrea

Answer 1

I think caching is a reasonable approach and you can take it a step further and add a SQL Dependency to it.

ASP.NET Caching: SQL Cache Dependency With SQL Server 2000

Answer 2

Writing a file is a better solution IMHO - its served by IIS kernel code, w/o the huge asp.net overhead and you can copy the file to CDNs later.

AFAIK dependency cashing is not very efficient with SQL Server 2000.

Answer 3

If you go the file route, keep this in mind.

http://petesbloggerama.blogspot.com/2008/02/aspnet-writing-files-vs-application.html

Answer 4

It depends on a lot of things:

• If there is little change in the data (think backend with "publish" button or daily batches), then I would definitely use static files (updated via push from the backend). We used this solution on a couple of large sites and worked really well.
• If the data is small enough, memory caching (i.e. Http Cache) is viable, but beware of locking issues and also beware that Http Cache will not work that well under heavy memory load, because items can be expired early if the framework needs memory. I have been bitten by it before! With the above caveats, Http Cache works quite well.

Answer 5

Also, one way to get around the memory limitation mentioned by Skliwz is that if you are using this service outside of the normal application you can isolate it in it's own app pool. I have seen this done before which helps as well.

Answer 6

Thanks all, as the data are little in size, but the underlying tables will change, I think that I'll go the HttpCache way: I need actually a way to reduce db access, even if the data are changing (so that's the reason to not using a direct Sql dependency as suggested by @Bloodhound).

I'll make some stress test before going public, I think.

Thanks again all.

Answer 7

Of course you could (should) also use the caching features in the SixPack library .

• Forward (normal) cache, based on HttpCache, which works by putting attributes on your class. Simplest to use, but in some cases you have to wait for the content to be actually be fetched from database.
• Pre-fetch cache, from scratch, which, after the first call will start refreshing the cache behind the scenes, and you are guaranteed to have content without wait in some cases.

More info on the SixPack library homepage. Note that the code (especially the forward cache) is load tested.

Here's an example of simple caching:

    [Cached]
    public class MyTime : ContextBoundObject
    {
            [CachedMethod(1)]
            public DateTime Get()
            {
                    Console.WriteLine("Get invoked.");
                    return DateTime.Now;
            }
    }