locked
Where is Session Store for State Server session mode RRS feed

  • Question

  • User-1362334014 posted

    InProc Server : Session data is stored in aspnet worker thread.
    State Server : Where is the session data stored?
    Sql Server: Serialized and store in sql tables.

    Is it stored in RAM memory ?
    Is it store in some physical files and automatically accessed for the session ?

    Saturday, December 6, 2014 5:18 AM

Answers

  • User753101303 posted

    As always this is a tradeoff. you have to double check that every byte of memory you are consuming will bring a proven benefit. Do you have seen originally some kind of problem and you decided to cache data Inside the session or do you have done this upfront? Always try to store as less data than possible. Can't you just update/read the db as needed etc...

    Hard to tell more without knowing more about your exact scenario but make sure to really show the users what he needs.  At first sight it seems you are storing too much data as if you cache a high number of rows more likely it means that most of them will be anyway useless to the user...

    Generally speaking session is for as less data you can and for data that are usefull for the whole user session.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, December 6, 2014 8:11 AM
  • User753101303 posted

    Having a user to deal with 100 000 rows at once is higly suspect. What is the exact requirement? I guess they won't see all those rows at once anyway? If they want to update some of them and then update them for real in one go you could likely use a dedicated table to handle those changes before "publishing" them.

    For now the problem is likely not how it is stored but rather what you need to cache 100 000 rows for each and every single user.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, December 8, 2014 4:30 AM

All replies

  • User753101303 posted

    Hi,

    In the RAM handled by this dedicated process (stricly speaking not 100% sure but it makes sense).

    Saturday, December 6, 2014 5:30 AM
  • User-1362334014 posted


    I guess the same, but not sure :)

    My application is having a lot of business logic operation applied on the fetched sql data. Currently, I have kept it in session and this is used during the to and fore request by the user (like change events, paging of grid and similar).

    My current session mode is inproc, which is stored in aspnet worker thread, which I guess is indirectly occupying RAM memory.

    So, in the cases, switching session from inproc to state server would be same as they both occupy RAM memory.
    Taking a scenario, I have 1 lac records, had business operation and saved in session (may taking around 15MB, determined when stored in file),
    If one user opens 20 of such heavy pages, it will occupy 15*20 = 300MB
    Adding, if there are 20 such users, it will occupy 300MB * 20 = 6000MB ~= 6GB

    Considering it being in RAM memory. In either cases, server will have performance issues ?
    So, will state server be helpful here ?
    or Sql Server will be helpful here ?
    Also, thought on the file saving and retrieving for such data -- this will only occupy tempoary physical memory  ?

    Which approach can prove useful ?

    Saturday, December 6, 2014 6:47 AM
  • User-782232518 posted

    It would be clearer to you if you try out the session modes based on your own testing data.

    Another hint is that Microsoft releases a fourth mode, using Redis,

    http://blogs.msdn.com/b/webdev/archive/2014/05/12/announcing-asp-net-session-state-provider-for-redis-preview-release.aspx 

    The NuGet package has been made production already.

    Saturday, December 6, 2014 7:50 AM
  • User753101303 posted

    As always this is a tradeoff. you have to double check that every byte of memory you are consuming will bring a proven benefit. Do you have seen originally some kind of problem and you decided to cache data Inside the session or do you have done this upfront? Always try to store as less data than possible. Can't you just update/read the db as needed etc...

    Hard to tell more without knowing more about your exact scenario but make sure to really show the users what he needs.  At first sight it seems you are storing too much data as if you cache a high number of rows more likely it means that most of them will be anyway useless to the user...

    Generally speaking session is for as less data you can and for data that are usefull for the whole user session.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, December 6, 2014 8:11 AM
  • User-1362334014 posted

    Yes, I agree to have minimal data in session, but due to business logic of financial data,
    Its required some time to have 1 lac records or could be lesser, apply business rules and show to user in edited form.User keeps on changing these data once displayed so they are in session.

    Additionally, for state server/sql state server, the entities need to be serialized only ?

    Here, I need to serialize all of my entites ?

    Is it ok to have [Serializable] attribute on entity classes or any disadvantages ?

    Alternatively, I was thinking on option to serialize data to json and save in file, retrieve the same and cast to object when needed. This helps in server memory issue, Is is appropriate approach or it has any flaws ?

    Any answer will be much appreciated :)

    Monday, December 8, 2014 3:21 AM
  • User753101303 posted

    Having a user to deal with 100 000 rows at once is higly suspect. What is the exact requirement? I guess they won't see all those rows at once anyway? If they want to update some of them and then update them for real in one go you could likely use a dedicated table to handle those changes before "publishing" them.

    For now the problem is likely not how it is stored but rather what you need to cache 100 000 rows for each and every single user.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, December 8, 2014 4:30 AM