User Level Data Caching

ghari · January 14th, 2006, 02:58 AM

Please dont mind if this is silly

But I really expect some people over there talking on this.

The issue is user level data caching.

Im very much excited with the various levels of data caching available with ASP.NET. Still to know its pros and cones.
Recently in one of my application I designed a user level data caching. This is how went on with that.

When creating a data cahche (with a dataset) I added the session ID along with that.

Code:

if(Cache.Get("chSearchResults" + Session.SessionID.ToString()) !=null)
Cache.Remove("chSearchResults" + Session.SessionID.ToString());
Cache.Insert("chSearchResults" + Session.SessionID.ToString(),dSetAdvancedSearchPropertyList,null,DateTime.Now.AddHours(5),Cache.NoSlidingExpiration);

I believe I now need to explain the reason why I used this technique.
Actually there are many entry point to the search results page.
So by applying this techinique I could create the resultant records well before entering into the search results page and could avoid massive amount of code.
It seems that the technique has reallly boosted the search speed as well (Yet to be tested in the client environment).

Please let me know if there is any problem applying this technique.
Also please let me know if there requires any further explanaions.

Imar · January 14th, 2006, 05:30 AM

Hi ghari,

Yeah, in my opinion, there are some *major* problems with this solution.

First of all, the cache is for general purposes and could and should be used site-wide. By tying it to a specific user with the SessionID you more or less make it user-bound, which is not the intention of the cache. To make things worse, you don't get a true separation of the data on a user by user base, so it's possible to access the data from one user in the page of another. That is, the cache doesn't prevent your pages from supplying a key from another session to retrieve other user's data. If you don't store secret information, that's not really a problem, but still it feels odd....

Secondly, by storing large search results in the Cache, you run a high risk of large memory consumption. Depending on the number of users you have on your site, cached items may even be removed from the cache before they can be reused again, resulting in slower responses instead of quicker responses.

Thirdly, I don't understand why you only add the item to the cache when it already exists. Are you not interested in storing it the first time? (Or didn't you show us all your code?)

Finally, why do you store the data in the cache for *5 hours*? That's an incredible long time for a web server. By default, a session times out after 20 minutes. After those 20 minutes, the session is gone, and so is its SessionID so there is *no* way to retrieve the cached item for the specific user / session.

So, all in all, this is a *very* bad idea.

The solution? It depends on your architecture and the specific type of application.

For example, if you're storing the results of a search operation for paging purposes, rework your data access layer and have it return only the requested number of records that are being displayed on the current "page" and don't return the entire result set. In SQL Server 2005 this is very easy, in 2000 and earlier you can write a stored procedure that inserts records in a temp table using an identity and then only returns the requested "page" of data. Slim, efficient and elegant, and definitely beats caching the entire dataset when you have a large number of search results.

If you need to store a search operation for a user so they can see the results on multiple pages, only store the search request / search term. Don't store it in the cache, but on a user by user basis in Session state. Based on this search term, get the required data whenever you need it.

After reading this, you may think I am against using the cache, but that's not true. The cache is a great feature to speed up access to frequently used and shared data. However, the way you are using it, doesn't seem to be the proper way to use the cache....

HtH and other opinions are more than welcome...

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

planoie · January 14th, 2006, 12:56 PM

My general opinion on just the topic of "where to store the data" is that if you are storing user specific data, you already have a mechanism that does it: the Session collection. There's no reason to use the web cache with user specific keys when you have the session that does it all for you.

That point aside, I agree completely with Imar's ideas.

-Peter

ghari · January 16th, 2006, 01:47 AM

Thanks!
It was really a foolish though:).
I will now try to use another alternative.
Storing in the session seems to a tough solution.
Could create many problems in the future, also there are can be 1000's of records returned with bulky amount of data.

My next choice would be temp table with sql server stored procedure.
Imar, could you please guide tome some link where I can get some real good examples of temp tables in sql server.
Or if possible please could you get me some tips here itself.
I will elaborate my idea.
I have a property listing application works carried on.
The listing page is reached from many search pages (more than 8). All with different types of inputs.
So writing the whole code in the search results page will reduce the maintainability of the code.
And writing different search result page for different searches is never a clever solution as well.

so I thought of something new by which the search processing is carried out on the search page itself and the result page will be responsible only for displaying the search.

Hmmm... Can anyone think of a better Idea.. Meanwhile I will be working on the SQL SERVER temp table concepts.

And not to forget.. You guys are simply awesome.
---------------------------------------------------------------
Thanks
Hareesh :)

ghari · January 16th, 2006, 03:52 AM

I have thought of another aproach.
Storing the command object as session variable and then execute the same from the search result page.::)
Any comments...?
I suppose the command object does not take much memory and I have the same old Idea implemented without much change in the code.
I would like to here from you on this.

planoie · January 16th, 2006, 10:01 AM

I don't think caching the command object makes much sense. That is only going to save the command information you have to execute. The point of caching would be to store the results from a database call so you don't have to get them every time. This is a practical solution for data that is fairly static. For me "Fairly static data" means that the set of data you get from the DB seldom changes. A good example of this could be a product category list. That kind of data may be used very often but doesn't change much and you'd typically use all of it all the time (in a category menu/selector). You would seldom change the set in the database itself, and when you do, you simply expire the cached version so it reloads from the DB.

A user's search result set is not a good candidate for caching because it will be very dynamic based on the user's search criteria.

Perhaps a different approach to this problem is to focus on optimizing your queries and/or the database structure. If you want to speed up the retrieval of the data you might be able to squeeze out some performance by tweaking the structure and/or indexes of the tables.

-Peter

Imar · January 16th, 2006, 01:08 PM

I agree with Peter that storing command objects in cache or session objects isn't going to be useful either.

As Peter points out, use the cache for data that doesn't change frequently.

For user specific data, storing the data in Session state isn't probably a good thing to do. Usually, I try to limit the amount of data I store in Session state to a user ID and a few other simple properties.

Something like search results are highly dynamic, so you should probably store the search term in session state (if that is what your application requires) and then execute the search operation every time you need it. Take a look at the following article for some ideas about smart paging with stored procedures:

http://www.4guysfromrolla.com/webtech/062899-1.shtml

It's written for ASP, but the same SQL Server principles apply.

Maybe your application needs a little different architecture. You say you have different search operations for the search page from different pages. How about implementing this search results list as a User Control. You can then give this User Control public properties like DataSource (for example, to set a DataSet with search results) or a property like SearchTerms (a custom class with various search options).

Then the hosting pages can load the SearchResults user control, set a few properties and then call, for example, DataBind to have the user control display its data.

This way, you have a flexible architecture that allows you to present the search results in a strict format defined only once (the SearchResults User Control), while you can still influence what it displays from many other pages....

HtH,

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

mypark · January 30th, 2006, 01:30 PM

All of the answers assume that the search results are very dynamic and the cost of running the search query is small. What if you have the opposite situation where the cost of the search query is quite large but results are pretty static; and the results need to linger and be accessible by page. Should one just store the id's of the search results and call some sort of get detail procedure to merge the ids to some more detail data every time someone requests a page of results? Should one store more than just the ids (specifically for getting a few more varchar fields)? Can one store cache the results for each user on the SQL side with SQL Server 2005? Shoud it be stored in session?

Imar · January 31st, 2006, 02:15 PM

In that case, the Cache seems like a good option.

However, it's important to realize the Cache applies to everyone, so it's not a good place to store sensitive or personalized data. But if it's about generic data that is hard to query, the cache would work.

As the cache key, you could use the search terms that users entered. That way, you know you get the same results with the same query, but fresh results if the search term has changed.

HtH,

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

planoie · February 1st, 2006, 01:00 AM

Quote:

quote:Originally posted by mypark
Can one store cache the results for each user on the SQL side with SQL Server 2005?

Perhaps, but wouldn't this just be moving the data? I imagine the CPU cost difference between pulling data "cached" in the database and just re-executing the original query is small and thus would defeat the purpose of "caching" it to a DB.

-Peter