Recently, I worked on a case where my customer was using ReportingViewer 10.0 and Azure Caching for session state management.
The application was relatively slower when using Azure Caching for session state management compared to using local caching.
After investigation, we determined that the session object was large. Since, Azure session management is done external to the machines running the asp.net service, the larger the session state object, the longer it takes to serialize and send the object to the external machines.
Network is also a contributing factor to the delay. (Imagine copying a large file from one folder to another folder on the same machine compared to copying from one machine to another machine in the same network)
In this scenario, the report viewer was creating an instance of the custom credentials class and storing it in the session. Which explained the large session oject size.
The key learnings are:
1. When you are using Azure Caching for Session State management, make sure that you have only the required things in the session state.
2. Avoid pushing unnecessary data (like static and constant data, thumbnails, etc. ) into Session Object.
3. The session object as a whole is serialized and pushed to cache servers.
4. Any update to the session object means full blob transfer between web role and cache servers (to and from) .
How to use Azure Caching for Session State Management: