Scalable Application Design

Discussion in 'ASP .Net' started by =?Utf-8?B?VGVycnkgSG9sbGFuZA==?=, Mar 17, 2006.

  1. Ive read that to build scalable web apps it is not recommended that state be
    stored in session variables.

    My understanding of this is that, with many users using the application
    concurrently, the amount of memory required to store all their session
    variables would very quickly exhaust the web server's memory. Also, if the
    application is to run on a web farm, there is no guarantee that all requests
    for a session will be dealt with by the same server. This could result in
    Session("MyVariable") being stored in the ram of Server 1 but as the next
    request might be dealt with on Server 2, it will be impossible to retrieve
    the value from Session("MyVariable").

    Is my understanding correct?

    Instead I should store state in sql serevr for example. I can see how I
    would easily do this with simple variables such as ForeName and DoB etc. Im
    not sure how to deal with something a bit more complex. One of the things I
    would my application does is, from a search page, have a collection of rows
    returned and then pass that collection as a parameter to a next page. At the
    moment I save my objResultsCollection in a session variable and then retrieve
    this object in the next page (my classes are serializable). How should I
    deal with this to make the application less dependent on session variables?
     
    =?Utf-8?B?VGVycnkgSG9sbGFuZA==?=, Mar 17, 2006
    #1
    1. Advertising

  2. =?Utf-8?B?VGVycnkgSG9sbGFuZA==?=

    Brian Guest

    "Terry Holland" <> wrote in message
    news:...
    > Ive read that to build scalable web apps it is not recommended that state
    > be
    > stored in session variables.
    >
    > My understanding of this is that, with many users using the application
    > concurrently, the amount of memory required to store all their session
    > variables would very quickly exhaust the web server's memory. Also, if
    > the
    > application is to run on a web farm, there is no guarantee that all
    > requests
    > for a session will be dealt with by the same server. This could result in
    > Session("MyVariable") being stored in the ram of Server 1 but as the next
    > request might be dealt with on Server 2, it will be impossible to retrieve
    > the value from Session("MyVariable").
    >
    > Is my understanding correct?


    This last part in incorrect.

    Many load balancing switches can keep the same user going to the same
    server. This has a timeout similar to the session timeout. The load
    balancing timeout needs to be higher than the web server session timeout
    otherwise the scenerio you described can occur.

    This doesn't load balance accurately for small scales like 100 concurrent
    users. For very large scales, statistics kick in and the load balancing is
    very fair.

    The disadvantage is shutdown complexity. If you need to take a server down,
    you take that fraction of users with it (assuming the session variables are
    maintained by the web server).

    We use Foundary switches. The setup is not trivial.
     
    Brian, Mar 18, 2006
    #2
    1. Advertising

  3. Terry

    Everything you read was true. Sessions == Evil. Well not really. This is the
    web. And because of the stateless nature of the web you will ineviably need
    to store things in the web.

    That being said, there are certain things you can do you reduce your
    dependency of sessions.

    I wouldnt store your session state in a sql server unless your app was in a
    webfarm. If it will then yea, you'll need to do that. Otherwise, you'll take
    a hit on performance.

    Rememeber that querystrings are our old but trust friends if you can get
    away with it. Also the rows you have could be serialized and stored in
    ViewState on a postback Or if you have to send them to the next page you
    could stick them in Context and available on a Server.Transfer().

    Ive had apps thats only store minimal user info in session and get
    everything i need from querystring, viewstate and context.

    HTH,
    T


    "Terry Holland" <> wrote in message
    news:...
    > Ive read that to build scalable web apps it is not recommended that state
    > be
    > stored in session variables.
    >
    > My understanding of this is that, with many users using the application
    > concurrently, the amount of memory required to store all their session
    > variables would very quickly exhaust the web server's memory. Also, if
    > the
    > application is to run on a web farm, there is no guarantee that all
    > requests
    > for a session will be dealt with by the same server. This could result in
    > Session("MyVariable") being stored in the ram of Server 1 but as the next
    > request might be dealt with on Server 2, it will be impossible to retrieve
    > the value from Session("MyVariable").
    >
    > Is my understanding correct?
    >
    > Instead I should store state in sql serevr for example. I can see how I
    > would easily do this with simple variables such as ForeName and DoB etc.
    > Im
    > not sure how to deal with something a bit more complex. One of the things
    > I
    > would my application does is, from a search page, have a collection of
    > rows
    > returned and then pass that collection as a parameter to a next page. At
    > the
    > moment I save my objResultsCollection in a session variable and then
    > retrieve
    > this object in the next page (my classes are serializable). How should I
    > deal with this to make the application less dependent on session
    > variables?
    >
    >
     
    Anthony Merante, Mar 18, 2006
    #3
  4. Hi,

    Anthony Merante wrote:
    > Rememeber that querystrings are our old but trust friends if you can get
    > away with it. Also the rows you have could be serialized and stored in
    > ViewState on a postback Or if you have to send them to the next page you
    > could stick them in Context and available on a Server.Transfer().


    I am not a big fan of ViewState myself. We developed a web application
    which runs many days, possibly even weeks without restarting IE. Some of
    the pages are automatically refreshing themselves using a postback. We
    found out that if the viewstate is big, this might cause a memory leak,
    because the previous page is cached in the browser's history. Granted,
    this is not a very common situation (web applications are mostly running
    a few hours maximum before the browser is restarted), but Microsoft
    acknowledged the problem, and we decided to move away from ViewState
    everywhere possible to avoid this kind of problems.

    HTH,
    Laurent
    --
    Laurent Bugnion, GalaSoft
    Software engineering: http://www.galasoft-LB.ch
    Private/Malaysia: http://mypage.bluewin.ch/lbugnion
    Support children in Calcutta: http://www.calcutta-espoir.ch
     
    Laurent Bugnion, Mar 18, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Grandy

    scalable state-management

    John Grandy, Mar 17, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    345
    Scott Allen
    Mar 18, 2005
  2. =?Utf-8?B?QnJlbnQgQm9yb3Zhbg==?=

    Scalable web architecture with ASP.NET 2.0

    =?Utf-8?B?QnJlbnQgQm9yb3Zhbg==?=, Dec 11, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    610
    =?Utf-8?B?QnJlbnQgQm9yb3Zhbg==?=
    Dec 12, 2005
  3. Ilya
    Replies:
    9
    Views:
    1,823
  4. Curtis
    Replies:
    13
    Views:
    662
    Curtis
    Dec 21, 2005
  5. Bryan
    Replies:
    2
    Views:
    273
    Jon Clements
    Oct 28, 2009
Loading...

Share This Page