If you have a web farm, then your web application is scalable, right? WRONG.
If you web application uses session variables and if you do not configure your site to use out-of-process sessions, then your application is tied to a single server and you will have to do some magic on your Load Balancer to make each request (from unique IPs) "stick" to the original server. This caused a problem in my company's environment because we have 2 reverse proxies that all traffic from the internet get routes through. So our Load Balancer only sees traffic from 2 IP addresses and there for only uses 2 of our 3 servers in the farm to serve up applications. So if we max-out our server capacity, even adding a 4th server will not resolve our issue as the load balancer with the "sticky" setting will still only direct traffic to 2 of the servers.
So, what can be done about that? We can make it so that the application can be served by ANY of the servers in the app pool because their session data is accessible to each of the servers in the Farm. This is done through the use of out-of-process sessions. You can read a lot about session servers around the internet, but basically, out of the box, if you start coding using Session[] variables, it just magically works. Most programmers starting out don't question HOW it works. It is default behavior of ASP.NET and the Session[] variables you are creating in your app are being stored by the w3wp.exe (ASP.NET) worker process. So, if you kill that process (like doing an iisreset), you will lose your session variables. Also, if you load balancer sends your request to another machine (and therefore another w3wp.exe process), your Session[] variables will also be lost.
Some programmers resort to stop the use of Session[] and instead use a database and write their own access methods. Other might choose to go down the VIEWSTATE path and keep their state in the screens. But there is an easier way that allows you to keep you easy to use Session[] variables: the ASP.NET State Server.
On your IIS Server, when you install ASP.NET, a service called ASP.NET State Server is installed, but it is installed turned "off". In order to use it, you must turn it on (that's about it), and you probably want to turn it on and set the start up mode to Automatic.
OK, so it's turned on, now what? How do you use it? Simple, place the following line into your web.config file:
How Civil Service Commission (Pre-Screen Application) was setup on QA for ASP.NET State Server.
For some basic Instructions, see:
http://dotnetguts.blogspot.com/2009/06/steps-for-session-inproc-mode-to.html
I turned on ASP.NET State Service on TempStaging by doing this:
1) Start >> Run >> Services.msc
2) "ASP.NET State Service" (installed automatically in "Manual Start" mode by ASP.NET)
3) Set "Start Up Type" to "Automatic"
Allow remote connections here (on TempStaging):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnection
In the application web.config, add this (in System.Web):
<--tcpip to 10.150.1.87 is the TempStaging server -->
<sessionState mode="StateServer" stateConnectionString="tcpip=10.150.1.87:42424" cookieless="false" timeout="120" />
Add a <machinekey> tag to your web.config as this is one of the unique identifiers the state server uses to identify sessions between different applications.
I installed the IIS6 Resource Kit (for the IIS Metabase editor) from:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17275
I tried using the Metabase Editor to make BOTH servers have the same "AppRoot" of:
/LM/W3SVC/1/ROOT/CivilServiceComm
per the knowledge base article found here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;325056
and:
http://www.justskins.com/forums/asp-net-session-state-138611.html
But, in the end, I had to create the Moveinstance.vbs script from the knowledge base article.
No comments:
Post a Comment