Last post Sep 03, 2010 04:29 PM by DigiMortal
Jan 24, 2008 02:02 AM|StevenPaul|LINK
I am sure this question has been posted many times, but have not got time to wade through. Apologies in advance!
I am working on a new web application which has extremely high volumes of traffic, the application uses two large(ish) data tables (approx 15,000 rows/records each - both fairly 'wide' tables....) which are each the result of various JOINS and other intensive
The post query operations are unavoidable and the data structure has been optimised wherever possible.
I am debating on using the Cache and CacheDependancy classes to store these tables, but fear the 'eviction' process due to the demand in traffic and server resources generally.
I can certainly afford to build these tables once, on the first request (near Application Start), but should memory become scarce, do not want the cached data to be recreated during the application lifecycle and have concerns about how ASP.NET will manage
demands on this data in such a crisis.
For example, if during a period of time, available memory is at an all time low, I would anticipate that the CacheDependancy would keep recreating the tables for each request. (I don't know...)
Note: The Cache API is not used elsewhere and the Application and Session scopes are hardly used.
At present, I am using just a static class to store the two tables which works amazingly well and the performance is as you would expect not having to access a datasource per request.
If I continue to use the static class approach, I appreciate that when available memory is consumed, I am left with the recycle process to deal with, but I am of the opion that this would still be favourable in preference to using the Cache API.
I would really appreciate to hear what other people think on this matter. Cheers all.
Jan 24, 2008 04:07 AM|siva_sm|LINK
ASP.NET does not recreate cached items by itself when they are accessed after removal. The general pattern is that when a cached item is accessed, check for its existance and recreate if required and cache it again.
With respect your scenario, I would go with static classes too because fetching data is costly and ASP.NET could remove the cached data under various circumstances. This is not going to be the case with static classes. The only down point with static is
that you need more memory and possibly change application pool settings to increase the memory recylcing limits. Finally it all depends on what you want to trade for what (memory vs db fetch performance).
Aug 30, 2010 03:54 AM|suthish nair|LINK
The only down point with static is that you need more memory and possibly change application pool settings to increase the memory recylcing limits
First of all, am sorry in replying an old post.
About your above statement, want to know more about it.
Do you have any documented material explaining this statement.
Sep 03, 2010 07:55 AM|Deleo|LINK
I would go for a cache framework, just because it has about the same performance and you have more refactoring options for the future.
By using static classes, you lock your application alot, by denying itself to evolve in the future.
By using cache framework you can easily add logic which could run on when cache is expired, how it is updated, how often, etc..
If you load data in static, it will be there forever and eventually corrupt. At some point you have to update it to reflect the changes in the database. At each database update, you could add SQLCachedependency :)
Sep 03, 2010 04:29 PM|DigiMortal|LINK
If you are using statics instead of cache you lose the opportunity to use different cache providers. Today may be it is okay for you to cache items to server memory of SQL database but when your application grows you probably prefer some distributed cache.
You don't refactor your statics easily to use cache providers. Take ASP.NET cache and use it.