none
Custom Session State provider based on Azure Cache makes the application very slow

    Question

  • Hi,

    I've spent the last 2 days struggling with an issue which seems very strange to me and to which I don't have any explanations. On short line, what I've done was like this - in order to reduce the number of database calls I've started to use the Windows Azure Cache as Custom Session State provider (backend info - I'm having an HTTP Module which takes a plain class from session and instantiate a custom principal and then it stores it back to current thread - instead of taking that class fields each time from database).

    Since I've done this thing, the application reduced the speed by at least 50% in response times - and I'm speaking about plain post backs which just populates 4 fields and display those. In order to be sure that the cause is the session state, I've commented out the custom session state declaration and I've put it back to inProc - the speed is back to 100%. This is happening on both environments - local development machine and also the azure deployment.

    And now - one more strange thing - I will take a step back and I will tell you why I oriented to custom session state based on azure cache - I've started to use the Azure Reporting and over-there you need to have a session server available or to disable the session state on the custom credentials class - so I've implemented the custom credentials with the standard implementation with the properties taken from the constructor and put into instance variables (according to the documentation this makes the ASP.NET to put the custom credentials class instance in the session state).

    Later Edit: And one more thing - ReportingViewer 10.0 has an issue with this kind of deserialization (Windows Azure Cache) and I had to use that patch from microsoft as startup task for the web-roles. Everything is ok but I'm having the impression that application starts to go slower and slower after I'm loading a report and then navigating to another page.

    Please help me by giving me a hint or something.

    Thanks.

    Evdin


    Monday, March 26, 2012 9:18 AM

Answers

  • Hello again,

    After spending some late nights on the phone with the US Azure Support representative (and I'm glad that I've did it) I've got the the point where I can tell what happened and which is the issue. Everything was about the ASP.NET Report Viewer - I know that is a bit incredible but this is the truth.

    In few short lines - if you get to the above described behavior, this are the guidelines and checklist that you have to think-about:

    a) don't specify the report server credentials manually for each report; instead, create a custom connection class based on IReportServerConnection interface and also specify it in the web.config file as application setting (<appSettings>) as follows:

    <add key="ReportViewerServerConnection" value="[FULL CLASS NAME W/ NAMESPACE, ASSEMBLY]"/> (the key name should be respect it as is)

    b) be sure that everywhere in your code, the reportviewer doesn't have set the report server url or the resport server credentials.
    c) in the above created class based on the IReportServerConnection, be sure that the values are always taken from the config file and not otherwise:

            public bool GetFormsCredentials(out Cookie authCookie, out string userName, out string password, out string authority)
            {
                authCookie = null;
                userName = WebConfigurationManager.AppSettings["RSUser"];
                password = WebConfigurationManager.AppSettings["RSPassword"];
                authority = WebConfigurationManager.AppSettings["RSDomin"];
                return true;
            }

    So, that's it. The technical explanation is pretty simple - the report viewer creates an instance of the custom credentials class and store it in the session and you get pretty quick to a very large session size.

    I hope that this helps.

    Evdin

    Thursday, April 19, 2012 8:35 AM

All replies

  • Hi,

    From my experience, it is understandable the application becomes slower in local environment, as we are saving cache data in the cloud instead of the local machine's memory. But I am not sure why it happens in the cloud as you mentioned. For now, I would like to suggest you to make sure you’ve followed the instructions on http://msdn.microsoft.com/en-us/WAZPlatformTrainingCourse_BuildingAppsWithCacheService.

    Best Regards,

    Ming Xu.


    Please mark the replies as answers if they help or unmark if not.
    If you have any feedback about my replies, please contact msdnmg@microsoft.com.
    Microsoft One Code Framework

    Tuesday, March 27, 2012 8:37 AM
    Moderator
  • You are using Windows Azure caching service right ? You have the local cache enabled ?

    Be nice to nerds ... Chances are you'll end up working for one!

    Tuesday, March 27, 2012 1:22 PM
  • Hi,

    I will mark the reply as an answer. If you find it no help, please feel free to unmark it and follow up.

    Thanks.

    Best Regards,

    Ming Xu.


    Please mark the replies as answers if they help or unmark if not.
    If you have any feedback about my replies, please contact msdnmg@microsoft.com.
    Microsoft One Code Framework

    Monday, April 2, 2012 4:03 AM
    Moderator
  • Hi,

    Sorry for not replying lately but I was out for a week. No - the issue is not solved and the ideea is that I'm not using the cache directly - I'm just using the Session Custom Provider build by Microsoft for Windows Azure Cache.

    And yes, I've enabled the local cache but it didn't helped. Please, tell me where else can I look for hints.

    Thanks,

    Evdin

    Wednesday, April 4, 2012 2:03 PM
  • Hello again,

    After spending some late nights on the phone with the US Azure Support representative (and I'm glad that I've did it) I've got the the point where I can tell what happened and which is the issue. Everything was about the ASP.NET Report Viewer - I know that is a bit incredible but this is the truth.

    In few short lines - if you get to the above described behavior, this are the guidelines and checklist that you have to think-about:

    a) don't specify the report server credentials manually for each report; instead, create a custom connection class based on IReportServerConnection interface and also specify it in the web.config file as application setting (<appSettings>) as follows:

    <add key="ReportViewerServerConnection" value="[FULL CLASS NAME W/ NAMESPACE, ASSEMBLY]"/> (the key name should be respect it as is)

    b) be sure that everywhere in your code, the reportviewer doesn't have set the report server url or the resport server credentials.
    c) in the above created class based on the IReportServerConnection, be sure that the values are always taken from the config file and not otherwise:

            public bool GetFormsCredentials(out Cookie authCookie, out string userName, out string password, out string authority)
            {
                authCookie = null;
                userName = WebConfigurationManager.AppSettings["RSUser"];
                password = WebConfigurationManager.AppSettings["RSPassword"];
                authority = WebConfigurationManager.AppSettings["RSDomin"];
                return true;
            }

    So, that's it. The technical explanation is pretty simple - the report viewer creates an instance of the custom credentials class and store it in the session and you get pretty quick to a very large session size.

    I hope that this helps.

    Evdin

    Thursday, April 19, 2012 8:35 AM