How can I cache private data in a webfarm for ASP MVC

Question

I am making a member based web app in ASP MVC3 and I am trying to plan ahead, at first our user base will not be huge, but as with any software the potential for a sudden volume spike is always a possibility.

Thinking ahead to this scenario, I know that the database is the bottleneck area on most web apps. We are using MSSQL 2008RS we will have dedicated servers with several client databases each client has there own database so if one server begins to bottle neck we can scale vertically or move some of the databases to a new server and begin filling it up.

To access the databases we use primarily LINQ 2 SQL and are currently re-factoring some of our code to make use of the IQueryable mechanisms to do a lazy load of content. but each page contains quite a bit of content from various parts of the database.

We also have a few large databases that are used for widgets in the program that rarely change but have millions of rows. The goal with those is to somehow sync them to the primary source and distribute them across several machines and then load balance those servers.

With this layout should I even worry about caching, or will the built-in caching mechanisms in MSSQL be sufficient?

If so where should I begin? I have looked briefly at app fabric but it looks as tho it is for Azure only?

Resources:

How to cache data in a MVC application

http://stephenwalther.com/blog/archive/2008/08/28/asp-net-mvc-tip-39-use-the-velocity-distributed-cache.aspx

http://stephenwalther.com/blog/archive/2008/08/29/asp-net-mvc-tip-40-don-t-cache-pages-that-require-authentication.aspx

score 2 · Accepted Answer · answered Feb 13 '11 at 19:52

2

Lazy loading is a performance killer. Its better to load the entire object graph with one join than to lazy load other properties. This is especially the case with a list of objects. If you iterate you'll end up lazy loading for each item in the list. Furthermore every call to the db has overhead. Less calls = better performance.
SO was a top 1000 website before it needed two database servers. I think you'll be ok.
If your revenue model says "each client will have its own database" than your scaling issues should be really easy to solve. Sounds like you already have a plan to scale up with more servers as your client base increases. Whats the problem?
Caching on the web tier is usually the first scaling fix you'll have to worry about. You probably don't need to do a fresh db call with each page request.

Overall this sounds like a lot of premature optimization. Your traffic hasn't reached a point where you need to be worried about scaling. Make these kinds of decisions at the last second possible.

answered Feb 13 '11 at 19:52

John Farrell

24,673
10
77
110

I suppose what I mean by lazy loading, is that Iqueryable stacks the queries on top of each other until I actually grab the data and then it makes one call to the database for less data than by grabbing 1 big chuck of data and the processing it down in memory. – ChaseAucoin Feb 13 '11 at 19:56
Thank you for your answer, glad to know I seem to have things somewhat under control. – ChaseAucoin Feb 13 '11 at 19:56
@chase that is query composition, not lazy loading – Marc Gravell Feb 13 '11 at 20:01
@Marc 250 to go to 200k, wow, hats off! Another terr.... ific painting is waiting for you. – Pekka Feb 13 '11 at 20:21
1

@Pekka - yes, I'm hoping to get there tomorrow. The weekend has been slow, unfortunately – Marc Gravell Feb 13 '11 at 20:26
@Marc My apologies for the misuse of terms, and thank you for the correction. – ChaseAucoin Feb 13 '11 at 20:39

score 1 · Answer 2 · answered Feb 13 '11 at 20:00

The database cache is different to most caches - it can if course load used data into memory and re-use query plans, but that isn't really a cache as such.

AppFabric is definitely not just azure; after all, I it was you wouldnt be able to install it (and use it) locally :) but in truth there is little between AppFabroc, redis and memcached (the latter lacks persistance, of course).

But I think you should initially look at using the inbuilt asp.net caching; both data caching via HttpContext.Cache, and caching of entire responses (or, in MVC 3, partials). Obviously you should have a broad idea of what data is used heavily by lots of requests, and is safe to re-use : cache that!

Just make sure you treat all cached FAA as immutable (if you need to update the cache, re-add a modified value; don't modify the existing objects) - reason: it won't work the same if you start needing to use distributed caching, as that uses serialization, and any changes you make won't be seen by the next request.

How can I cache private data in a webfarm for ASP MVC

2 Answers2