Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Scalable Application Design

Reply
Thread Tools

Scalable Application Design

 
 
=?Utf-8?B?VGVycnkgSG9sbGFuZA==?=
Guest
Posts: n/a
 
      03-17-2006
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?


 
Reply With Quote
 
 
 
 
Brian
Guest
Posts: n/a
 
      03-18-2006

"Terry Holland" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.





 
Reply With Quote
 
 
 
 
Anthony Merante
Guest
Posts: n/a
 
      03-18-2006
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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?
>
>



 
Reply With Quote
 
Laurent Bugnion
Guest
Posts: n/a
 
      03-18-2006
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How would you design scalable solution? Bryan Python 2 10-28-2009 06:20 AM
Scalable fonts in nested lists... Curtis HTML 13 12-21-2005 08:15 PM
Scalable web architecture with ASP.NET 2.0 =?Utf-8?B?QnJlbnQgQm9yb3Zhbg==?= ASP .Net 3 12-12-2005 05:12 PM
scalable state-management John Grandy ASP .Net 1 03-18-2005 02:52 PM
help request: css positioning & text bg scalable image Ilya HTML 9 06-30-2004 02:24 PM



Advertisments