----------------------------------------------------------- New Message on cochindotnet
----------------------------------------------------------- From: SecCode Message 6 in Discussion Resending as plain text.. The HTML formatting in the original message seems to be playing havoc with readability. - Anil ________________________________ Long Post.. Be prepared :-) Some background and definitions to level-set before we start on the State Service itself. You typically employ the Out Of Process state management options when you need to scale out your application on a web farm. A web farm by its very definition is a group of servers that are used to distribute the load across multiple nodes (servers). This can be accomplished using hardware load balancers like Ciso LocalDirectors, F5 Big IP's or others. It can also be done using the Network Load Balancing (NLB) software that comes with the Enterprise version of Windows 2000 and Windows 2003. As load increases, it is simply a matter of adding more servers into the load balanced pool to distribute the incoming requests. The primary reason that we need to save state in a separate location (rather than inprocess/memory) is that, due to the stateless nature of the web, there is no guarantee that a two browser requests will be served out by the same machine. Ex. You could submit some form on the web that authorizes you by putting something in session, but on the next request, you could be bounced to another machine, that does not have that authorization session variable in its InMemory store. So what is needed is a storage mechanism that ALL nodes/machines in the web farm can point to and share. Session-State Storage Mechanisms ========================== ASP.NET supports three separate state storage mechanisms. 1. In Process - Session state is stored in-process to the ASP.NET worker process ( i.e in aspnet_wp.exe) which is similar to what we have in classic ASP. 2. State Server - Session state is stored in an external "State Server" process on a remote machine or a single member of a web farm. 3. SQL Server - Session state is stored in a SQL Server database (Can be on the web server or on a remote machine) The performance impact of each storage mechanism increase as you move from the In Process to SQL Server with In-Process being the fastest and SQL server being the slowest. As a comparison, the design goal of the ASP.NET team was to provide at least 80-85% of the performance for the SQL server option as compared to In-Process. According to my conversation with Scott Guthrie (ASP.NET Architect and Group Product Leader) internal perf testing has shown them hitting this goal. There is only a couple of % points of diff between SQL Server and State Storage so the choice between them should NOT be made based on the performance criteria. 1. In-Process State Storage Option This is similar to what we currently have in the Classic ASP model. Pros: . Default Option . Fastest performance Cons: . Constrained to single machine. Restart IIS or reboot machine and session state goes away. . Cannot share session across members of a web farm or a web garden. 2. State-Server Storage Option This is a new option under ASP.NET. Session state storage is in a dedicated "state server" process that can be enabled either on a single machine in a web farm or a separate machine outside the web farm dedicated to this process. The "State Server" is actually a running instance of a Windows Service named "Aspnet_state.exe". Pros: . Ability to share sessions across a web farm. . Session state can survive web farm reboots and IIS restarts the machine that is hosting the state is not the one in question. Cons: . Slower than in-process model as session data travels across process or machine boundaries. . The state server machine is a single point of failure as it cannot be clustered. . The state server machine cannot be taken out of service for routine maintenance without affecting the entire web farm. . Need for a separate machine at additional cost outside the web farm for true state support. 3. SQL Server Session State This is a new option under ASP.NET. This option offers the ultimate in scalability and reliability. It moves the Session State out of the ASP.NET worker process into a SQL Server 2000 DB. Pros: . Web farm compatibility as all machines in a web farm can be pointed to a single SQL server. . The SQL server can be clustered for reliability and scalability so there is no single point of failure. . Preservation of state under both IIS restart and web server reboot scenarios. . Taking a web farm out of service will not have any impact on state. Cons: . Slowest of the three options. . A clustered SQL server as the State repository for true reliability. Recommendation ================ Use SQL Server State Management option if you have a choice. . To provide true reliability with the State Server option, we would need to provide a dedicated server, outside the web farm, at each load-balanced tier. And the state server would be a single point of failure as Out of Process State Servers cannot be clustered. . In terms of pure performance, SQL Server is the slowest of the three options. But in return for speed, we have a virtual guarantee that Session State will not be lost. . Testing indicates that the while the SQL server is still the slowest, it is off only by a few percentage points as compared to the State Server option making it very viable from the performance perspective as well. . Reliability is guaranteed, as you can host the SQL Server database on a clustered SQL Server 2000 Platform. (Which I believe answers your question about a fail safe session storage mechanism) NOTE to Admins: Each machine's machine.config contains a machinekey element that assigns values to two Crypto keys, validationKey and decryptionKey. Default is for each machine to AutoGenerate these values which work fine when you are using a single box. But when deploying on a web farm, each server MUST use identical keys, otherwise a value encrypted/hashed on one server can't be unencrypted on the others ( For e.g. You will get a message that Viewstate is corrupt ). NOTE to DEVs: One item to be aware of when using either a State Server or SQL Server for session state storage is that both require that the types stored in session state be serializable. Non-Serializable types work just fine in In-Process sessions, so this issue will be encountered only when using either a State Server or SQL Server for state storage. Serialization is the process of writing data that defines an object instance to a storage mechanism for the purpose of recreating it at a later time and/or place. ASP.NET must be able to serialize objects stored in session state in order to store them to a State Server or SQL server and be able to deserialize them to read them back. Basically what this means for developers who are using this mechanism is that, if they are creating custom data types which will be stored in SQL Server or State Server, they MUST use the "Serializable" attribute, which will allow ASP.NET to use the .NET Framework Binary Formatter to serialize and deserialize the data type. Regards, - Anil -------------------------------------------------------------- -- http://SecureCoder.com -- Digital Security in an Insecure World -------------------------------------------------------------- ----------------------------------------------------------- To stop getting this e-mail, or change how often it arrives, go to your E-mail Settings. http://groups.msn.com/cochindotnet/_emailsettings.msnw Need help? If you've forgotten your password, please go to Passport Member Services. http://groups.msn.com/_passportredir.msnw?ppmprop=help For other questions or feedback, go to our Contact Us page. http://groups.msn.com/contact If you do not want to receive future e-mail from this MSN group, or if you received this message by mistake, please click the "Remove" link below. On the pre-addressed e-mail message that opens, simply click "Send". Your e-mail address will be deleted from this group's mailing list. mailto:[EMAIL PROTECTED]
