Last post Jan 16, 2015 02:34 PM by pelalusa
Jan 15, 2015 08:24 PM|pelalusa|LINK
I have a string representing the HTML code that makes up a jQuery menu which is about 14KB in size. Creating the string initially and storing/retrieving it in a Session object definitely improves performance versus rebuilding it from scratch for every page
After all of my work to achieve this was complete, I tried using the ASP.NET Cache object instead. Running 10 performance tests with FireBug, the Cache *seemed* to improve the page load performance a little over the Session object.
Here are my questions:
Jan 16, 2015 02:38 AM|Mikesdotnetting|LINK
Cache is application wide. Session is per user. If you use session, you will have as many copies of the menu in memory as you have current users. The menu will also be regenerated every time a new session is started. Using session for this is not the right
choice unless the menu is customisable by user.
Jan 16, 2015 02:01 PM|pelalusa|LINK
Mike, understood re the scope differences of Session vs. Cache.
Now, what about the speed differences: Is there some technical reason why the Cache would provide quicker retrieval times than the Session?
Jan 16, 2015 02:30 PM|Mikesdotnetting|LINK
Is there some technical reason why the Cache would provide quicker retrieval times than the Session?
No. And I doubt that your tests confirmed that one way is quicker than the other. Firebug doesn't/can't provide any metrics in respect of server-side code execution times.
Jan 16, 2015 02:34 PM|pelalusa|LINK
Understood, but repeated page loading times of using the Cache vs. using the Session seemed to indicate a slight improvement.
In any case, we're going to go forward with the Cache because the menu HTML I described earlier is shared by everyone so there's no need to store it separately in a Session object for each user.
Thank you again for your help!