views:

277

answers:

3

Hello,

I'm still yet to find a decent solution to my scenario. Basically I have an ASP.NET MVC website which has a fair bit of database access to make the views (2-3 queries per view) and I would like to take advantage of caching to improve performance.

The problem is that the views contain data that can change irregularly, like it might be the same for 2 days or the data could change several times in an hour.

The queries are quite simple (select... from where...) and not huge joins, each one returns on average 20-30 rows of data (with about 10 columns).

The queries are quite simple at the sites current stage, but over time the owner will be adding more data and the visitor numbers will increase. They are large at the moment and I would be looking at caching as traffic will mostly be coming from Google AdWords etc and fast loading pages will be a benefit (apparently).

The site will be hosted on a Microsoft SQL Server 2005 database (But can upgrade to 2008 if required).

Do I either:

  1. Set the caching to the minimum time an item doesn't change for (E.g. cache for say 3 mins) and tell the owner that any changes will take upto 3 minutes to appear?

  2. Find a way to force the cache to clear and reprocess on changes (E.g. if the owner adds an item in the administration panel it clears the relevant caches)

  3. Forget caching all together

  4. Or is there an option that would be suit this scenario?

+4  A: 

Premature optimization is the root of all evil ;)

That said, if you are going to Cache I'd use a solution based around option 2.

You have less opportunity for "dirty" data in that manner.

Kindness,

Dan

Daniel Elliott
+5  A: 

If you are using Sql Server, there's also another option to consider:

Use the SqlCacheDependency class to have your cache invalidated when the underlying data is updated. Obviously this achieves a similar outcome to option 2.

I might actually have to agree with Agileguy though - your query descriptions seem pretty simplistic. Thinking forward and keeping caching in mind while you design is a good idea, but have you proven that you actually need it now? Option 3 seems a heck of a lot better than option 1, assuming you aren't actually dealing with significant performance problems right now.

Kurt Schindler
Yes I forgot to mention this, I will add a comment to the question. Looking at your suggestion now :)
Phil
Maybe you should look at ORM tool (eg. NHibernate) which have embedded mechanism for caching data.
dario-g
A: 

2nd option is the best. Shouldn't be so hard if the same app edits/caches data. Can be more tricky if there is more than one app.

If you can't go that way, 1st might be acceptable too. With some tweaks (i.e. - i would try to update cache silently on another thread when it hits timeout) it might work well enough (if data are allowed to be a bit old).

Never drop caching if it's possible. Everyone knows "premature optimization..." verse, but caching is one of those things that can increase scalability/performance of application dramatically.

Arnis L.