Scalable Application Design

[Guest]

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?

 

[Brian]

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.

 

[Anthony Merante]

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

 

[Laurent Bugnion]

Hi,

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