Last post Jan 26, 2011 12:09 AM by Wenchao Zeng - MSFT
Jan 23, 2011 04:46 AM|sephiroth100|LINK
Looking for some advice or tips.
I have a website which could potential have lots of users. Let's assume a target of 1million and half a percent are online at any one time (5,000) for numbers sake.
Some of the pages on my website are general (i.e stores by category) and some are user specific (i.e. a users favourite stores).
Let's assume that 25% of users have favourite stores and they have an average of 50 stores each (total = 12.5 million). This would be the size of the user/store table.
My site may need to call on the user_store table many times during a visit so it makes sense to look at the table once and store the information for the duration of the users visit. I've toyed with a number of ideas and know what my current preferred solution
is but thought I'd throw it open to the experts on here who have vastly more experience than I do.
I have discounted profiles in that, whilst it provides some programming shortcuts, it doesn't cut down the size of the data that is bieng retrieved each time (unless someone tells me otherwise) and the main aim is to make the presentation of user data as
quick and efficient as possible.
Read the data from user_store once and store in session. Session would be set to SQL Server mode to cope with the amount of data.
Pro's: unlimited data can be stored in session, data stored as 5000 x List<T>, persistence advantages of using SQL Server mode
Con's: performance impact on all session stored variables
Read the data from user_store once and store in a cookie.
Pro's: small amounts of data being retrieved (1 string which could be parsed to return store ID's)
Con's: functionality won't work with cookies turned off, extra work parsing cookie value and managing synchronisation with user_store table, upper limit on what a user can store
I already have the functionality to do both and my preference at this stage would be solution 1, but I'm open to any advice being offered.
Thanks in advance
Jan 23, 2011 01:53 PM|Lateef045|LINK
Cookie is definitely not the idea. It gets sent to the webserver everytime a page is requested.
Sessions option is much better than the cookie.
And you should also be using the Cache.
Jan 24, 2011 05:45 AM|sovitmittal|LINK
Try to use the sqldependentCache to retrive the data.
Jan 24, 2011 06:03 AM|vijaybyadav|LINK
I would suggest to use cache.
Jan 24, 2011 09:41 AM|sephiroth100|LINK
Thanks for the prompt reply.
I already use cache for my main product data as it stays relatively static across the site and is updated every hour.
The data I'm referring to is user specific and will only benefit a single user. I've no idea how cache would be useful or how it could be used in for this type of data. Please could you provide a little more info.
Jan 24, 2011 10:53 AM|budugu|LINK
The data I'm referring to is user specific and will only benefit a single user. I've no idea how cache would be useful or how it could be used in for this type of data.
If you are trying to persist data specific to use, Cache is NO good for you. Try session or cookies. You may want to read this..
ASP.NET State Management Recommendations
Jan 26, 2011 12:09 AM|Wenchao Zeng - MSFT|LINK
I would suggest you use Cache in the
business layer and cache data only in the first visit. For example:
// This is one method in the Business Layer.
List<Item> GetItems(string userId)
// Only call Data Access Layer when the data is not cached.
if (HttpContext.Current.Cache[userId] ==
HttpContext.Current.Cache[userId] = DataAccessLayer.GetItems(userId);
// Return the cached data.
List<Item> items = (List<Item>)HttpContext.Current.Cache[userId];
please utilize SqlCacheDependency (as
Sovit suggested) to update the cache when the database is updated.
For more information, please see
Caching Application Data and
Caching in ASP.NET with the SqlCacheDependency Class.
Hope this helps.