Caching individual keys vs caching dictionary of keys in ASP.NET web API

Question

I need to cache information about user roles in ASP.NET Web API. I have decided to use System.Web.Helpers.WebCache class. Role is plain string, which is about 40 character long. Each user may have between 1-10 roles.

I am thinking of two ways to do this:

1. Use WebCache.Set(UserID, List<String>). Use user id as key and store List of roles (string) as value. Its easy to retrieve.
2. Use dictionary, where I will use userId as key and list of roles as value & then cache the dictionary. This way I am caching with only one key. When I retrieve this information, I first retrieve dictionary and then use user id to get the role information.

Questions:

1. Which approach is better? I like approach one as its easy to use. Does it have any downside?
2. The way I calculated memory use for keeping these keys into cache is by adding same amount of data (stored 10 roles of type string into) into a notepad and then calculated the size of the notepad (used UTF-8 encoding). The size was about 500 bytes and size of disk was 4 KB . Then if I have 200 users, I will multiply 200 * 500 bytes to calculate the memory usage. Is this right (I am ok if approximately closed) way to calculate?

Answer 1

I prefer the approach of saving individual keys instead of saving the roles of all users as a single cache object.

Following are the reasons:

1) Creation is simple, when user logs in or at an appropriate moment in time, the cache is checked for and 'if empty' created for that user, no need of iterating through the dictionary object (or LINQ) to get to that key item.

2) When user logs off or at an appropriate moment, the cache object is destroyed completely instead of only removing that particular key from cache.

3) Also no need of locking the object when multiple users are trying to access the object at the same time and this scenario will happen. Since object is created per user, there is no risk of locking that object or need to use synchronization or mutex.

Thanks, Praveen

Answer 2

1. Solution one is preferrable. It is straightforward and appears to only offer advantages.

2. Your calculation makes sense for option 1 but not for option 2. AC# dictionary using hashing takes up more memory, for primitive and short data like this, the data taken by hashes may be a significant increase.

The memory storage in individual bytes for this type of application would typically be a secondary concern compared to maintainability and functionality, this is because user roles are often a core functionality with fairly large security concerns and as the project grows it will become very important that the code is maintainable and secure.

Caching should be used exclusively as an optimization and because this is related to small amounts of data for a relatively small user base(~200 people) it would be much better to make your caching of these roles granular and easy to refetch. According to the official documentation on this library

Microsoft system.web.helpers.webcache

In general, you should never count on an item that you have cached to be in the cache

And because I'll assume that user roles defines some fairly important functionality, it would be better to add queries for these roles to your web API requests instead of storing them locally.

However if you are dead set on using this cache and refetching should it ever disappear then according to your question, option one would be a preferrable choice.

This is because a list takes less memory and in this case appears to be more straight forward and i see no benefits from using a dictionary.

Dictionaries shine when you have large datasets and need speed, but for this scenario where all data is already being stored in memory and the data set is relatively small, a dictionary introduces complexity and higher memory requirements and not much else. Though the memory usage sounds negligible in either scenario on most modern devices and servers.

While a dictionary may sound compelling given your need to lookup roles by users, the WebCache class appears to already offer that funcitonality and thus an additional dictionary loses its appeal

Answer 3

Q1: Without knowing the actual usage of Cache items, it is difficult to draw the conclusion. Nonetheless, I think it all comes down to the design of the life spam for those items. If you want to retire them all in once for certain period and then query a new set of data, storing a ConcurrentDictionary which houses users and roles to WebCache is a easier managing solution to do so.

Otherwise, if you want to retire each entry according to certain event individually, approach one seems a rather straight forward answer. Just be mindful, if you choose approach two, use ConcurrentDictionary instead of Dictionary because the latter is not thread safe.

Q2: WebCache is fundamentally a IEnumerable>, thus it stores the key strings and the memory locations of each value, apart from the meta data of the objects. On the other hand, ConcurrentDictionary/Dictionary stores the hash codes of key strings and the memory locations of each value. While each key's byte[] length is very small, its hashcode could be slightly bigger than the size of the string. Otherwise, the sizes of HashCodes are very predictable and reasonably slim(around 10 bytes in my test). Every time when you add an entry, the size of the whole collection increment about 30 bytes. Of course this figure does not include the actual size of the value as it is irrelevant to the collection.

You can calculate the size of the string by using:

System.Text.Encoding.UTF8.GetByteCount(key);

You might also find it useful to write code to achieve the size of an object:

static long GetSizeOfObject(object obj) 
{
    using (var stream = new MemoryStream())
    {
        BinaryFormatter formatter = new BinaryFormatter();
        formatter.Serialize(stream, obj);
        return stream.Length;
    }
}

Answer 4

First of all make sure there will be abstract layer and you can easyly change implementation if future. I cant see any significant difference between this two approaches both of them use hashtable for search. But second use search two times I suppose, when it serch dictionary in cache and when it search user in dictionary. I whold recommend in addition

1. if users are huge amount , store not roles as strings but roles Ids. if there are 1000-10000 of no sence to do it

2. List item

   Do not forget to clear cache record when user roles are updated

Answer 5

You don't need option 2, option 1 should suffice as all you need is key,list<string> .

Few points to consider in general before using caching:-

• What is amount of data being cached.
• What mode of caching are you using In Memory/Distributed.
• How are you going to manage the cache.
• If data being cached grows beyond threshold what is the fall over mechanism.

Cache has its pros and cons, In your scenario you have already done the payload analysis so I don't see any issue with option 1.