Question

What’s the best way to cache web site user data in asp.net 4.0?

I have a table of user settings that track all kinds of user or session specific stuff like the state of UI elements (open/closed), preferences, whether some dialog has been dismissed, and so on. Since these don’t change very often (for each user, anyway) but are looked up frequently it seems sensible to cache them. What’s the best way? These are the options I’ve identified…

1. Store them in HttpContext.Current.Session directly (e.g. Session["setting_name"])
2. Store them in HttpContext.Current.Cache
3. Use a global static dictionary, e.g. static ConcurrentDictionary<string,string> where the key is a unique userID + setting name value
4. Store a dictionary object for each session in Session or Cache

What’s the most sensible way to do this? How does Session differ from Cache from a practical standpoint? Would it ever make sense to store a dictionary as a single session/cache object versus just adding lots of values directly? I would think lookups might be faster, but updates would be slower since I’d have to re-store the entire dictionary when it changed.

What problems or benefits might there be to using a global static cache? Seems like this would be the fastest, but I’d have to manage the size. I could just flush it periodically if it hits a certain size, or keep a cross reference queue and remove things oldest first when it gets to a certain size. Does this make any sense or is it just trying too hard?

Answer 1

Session may end up being stored out-of-process or in a database, which can make retrieving it expensive. You would likely be using a session database if your application is to be hosted in a server farm, as opposed to a single server. A server farm provides improved scalability and reliability, and it’s often a common deployment scenario. Have you thought about that?

Also, when you use Session not in-process, it ends up getting serialized to be sent out-of-process or to a database, and deserialized when retrieved, and you are effectively doing what you describe above:

… updates would be slower since I’d have
to re-store the entire dictionary when
it changed. …

.. since, even if you use individual session keys, the entire Session object for a user is serialized and deserialized together (all at once).

Whereas, Cache would be in memory on a particular server in the farm, and therefore much more efficient than going out of process or to the database. However, something in cache on one server might not be in cache on another. So if a user’s subsequent request is directed to another server in the farm, the cache on that server might not yet hold any of the user’s items.

Nevertheless, I’d suggest you use Cache if you’re caching for performance reasons.

p.s. Yes, you’re trying too hard. Don’t reinvent the wheel unless you really need to. 🙂