Managing Performance using Out-of-Process Session State

Out of process session management becomes necessary when deploying ASP.Net web application in a NLB or Web warm. As well sometimes developers do you SQL server for session management because it is a more robust state management option and has more persistence than a memory-based state server. SQL Server option also allows for state to be maintained even across server reboots, because the data for the session persists into SQL Server.

However there can be a serious performance  degradation if developers do not tune the application while using Out of Process session management. By default, ASP.NET assumes that every page requires session state to be loaded during page initialization and to be flushed after the page has finished rendering. When using out-of-process session state, this means two round-trips to the state server (or database server) for each page rendering. But with a careful design potentially many of these round-trips can be eliminated. The idea is to direct the session manager to determine when session state must be retrieved and stored by querying the current handler’s session state requirements. There are three options for a page (or other handler) with respect to session state. It can express the need to view session state, to view and modify session state, or no session state dependency at all. When writing ASP.NET pages, express this preference through the EnableSessionState attribute of the Page directive.

<%@ Page Language=”C#” AutoEventWireup=”true”  CodeFile=”Default.aspx.cs” Inherits=”_Default” EnableSessionState=”ReadOnly” %>

The possible values for EnableSessionState are:

  1. True
  2. False
  3. ReadOnly

This attribute defaults to true, which means that session state will be retrieved and saved with each request handled by that page. If we know that a page will only read from session state and not modify it, we can save a round-trip by setting EnableSessionState to ReadOnly. Furthermore, if we know that a page will never use session state, we must set EnableSessionState to False. Internally, this flag determines which of the tagging interfaces the Page class will derive from (if any). These tagging interfaces are queried by the session manager to determine how to manage session state on behalf of a given page. Thus setting this tag carefully can boost the performance of the application significantly.

Advertisements

Session State in web farms

Recently I was working on a application that was required to be hosted on multiple web servers. Sounds simple and many of us has already done so may be more than once. One of the key issues that arise is maintaining session states across multiple web servers so that the user request can be routed to any web server. Asp .Net provides very elegant solutions out of the box. We can use Sql Server or an additional State Server. The mechanism used is called OutOfProcess Session Management. Whenever out-of-process session state is specified, it is also important to realize that anything placed into session state is serialized and passed out of the ASP.NET worker process. Thus, any type that is stored in session state must be serializable for this to work properly.
[Serializable]
public class YourClassName
{
// class implementation
}

StateServer mode stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

The .Net Framework Installs a service called ASP .Net State Service which handles the sessions when Out of Process.

aspnet state service

In order to set up SessionState server modify the web.config

<configuration>
<system.web>
<sessionState mode=”StateServer”stateConnectionString=”192.168.1.103:42424″ />
</system.web>
</configuration>

42424 : is the default port. It can be updated by setting the registry entry : HKLM\System\CurrentControlSet\Services\aspnet_state\Parameters\Port

To configure SQLServer Mode, you must run InstallSQLState.sql on the database. The primary purpose of this script is to create a table that can store client-specific state indexed by session ID in the tempdb of that SQL Server installation. The ASP state table is created in the tempdb database, which is not a fully logged database, thus increasing the speed of access to the data. In addition to storing the state indexed by the session ID, this table keeps track of expiration times and provides a locking mechanism for exclusive acquisition of session state. The installation script also adds a job to clean out all expired session state daily.

<configuration>
<system.web>
<sessionState mode=”SQLServer” sqlConnectionString=  “data source=192.168.1.103;user id=sa;password=” />
</system.web>
</configuration>
Note: no database is specified in the connection string because it is assumed tobe TempDB.

Both the state server and the SQL Server session state options store the state as a byte stream—in internal data structures in memory for the state server, and in a VARBINARY field (or an IMAGE field if larger than 7KB) for SQL Server.

Beacon IT Gold Coast Office

This week I got a chance to visit Beacon’s Gold Coast office. I was on BIDS 201 training. I didn’t mention before in my blogs, BIDS is a great Rapid Application developemnt tool. In short it allows to create full secure web application without writing a line of code. The whole appliation is ASP.Net 2.0 (C#) compliant. On top of that BIDS allows to integrate exisitng ASP.Net applications or Web Controls seemlessly in the code it generates. Wonderful tool. I met the System designer and other developers who developed it. Had a bit of discussion what the development strategy is and what the vision is for the product. The team is great.

We went out to a Japanese Tapinaki restaurant “Shogun” for a dinner. Some Asahi, local Japanese beer and lots of food. Great Stuff. Definitely on my agenda if I visit back again.

Friday I will be heading back to Sydney. Its been a great week. Lots of fun. A lot of training and above all a chance to meet the developement team.

Debugging ASP.Net on WIN 2003

Has anyone of you ever felt the need to debug a web application on Windows 2003 Server. Well some time back I had deployed an application on the test server which was Windows 2003 R2 Server, IIS 6 and ASP .Net 2.0. Normally we have Windows XP operating system in our development environment. When debugging with Visual Studio, developers tend to use the F5 key or attach to aspnet_wp.exe; which is the asp net worker process. However there is no aspnet_wp.exe running on Windows 2003. Instead the process is called w3wp.exe. It is a network process . So you must attach to this process in the visual studio and not looking for aspnet_wp.exe. But what is this w3wp.exe.

w3wp.exe is a process associated with application pool in IIS. If you have configured more than one application pool, you will have more than one instance of w3wp.exe running.

Application pools are a feature of IIS6, which is installed on Windows 2003 server by default. However IIS 5 is installed on XP. And I don’t think Microsoft allows intalling IIS 6 on windows XP.  Application pools provides a great way of isolating web applications thereby increasing the overall realibility of web applications.

protected internal .net access modifier

There are five access modifiers in .Net

  1. private
  2. public
  3. protected
  4. internal
  5. protected internal

While the first four are pretty straight forward, developers get confused with the protected internal. Many developers think members marked as protected internal may be accessed only by a descendant class that’s contained in the same assembly as its base class. However the key thing to note is protected internal is a union of protected and internal in terms of providing access but not restricting. This implies

  • Inherited types, even though they belong to a different assembly, have access to the protected internal members, and,
  • Types that reside in the same assembly, even if they are not derived from the type, also have access to the protected internal members.

protected internal means protected or internal, which is selected by including both a protected and an internal modifier in the member declaration.

Posted in .net. 3 Comments »