Enabling session compression in ASP.NET 4.0

Session objects are vital components in most of web applications. ASP.NET provides a few options to store the sessions, such as in-proc and out-proc. In-proc sessions are stored in the worker process memory while the out-proc sessions are stored in another process. You have two options when working with out-proc sessions: SQL Server or State Server.

Although storing large data in session objects is not recommended and should be avoided in most of the scenarios, sometimes you may need to store big data in session objects. Thanks to ASP.NET 4.0, now you can compress the data stored in the session objects. Compression will happen using GZip method.
However it only makes sense to compress the session data when you store the sessions out- proc, either in a SQL Server or in a state server.
How to store sessions in state server
You need to modify your web.config file as seen below:

        <sessionState mode="StateServer" stateConnectionString="tcpip=" />

Also, you need to start the ASP.NET State Service in the server, if it is not running.

Enabling the compression for session data

It is also an easy task. All you need to tell the ASP.NET that you are using compression for session states. You just need to modify the tag above as seen below:

<sessionState mode="StateServer" stateConnectionString="tcpip=" compressionEnabled="false" />
Testing the results

Consider the following scenario:

You are populating a DataTable with 20000 rows with the following code:

    public static DataTable GetAllData ()
        DataTable dt = new DataTable();
        DataRow dr;
        DataColumn dc;
        dc = new DataColumn("id"typeof(Int32));
        dc.Unique = true;
        dt.Columns.Add(new DataColumn("ProductName"typeof(string)));
        dt.Columns.Add(new DataColumn("Description"typeof(string)));
        dt.Columns.Add(new DataColumn("Price"typeof(string)));
        for (int i = 0; i < 20000; i++)
            dr = dt.NewRow();
            dr["id"] = i;
            dr["ProductName"] = "Product " + i;
            dr["Description"] = "Description for Product " + i;
            dr["Price"] = "$100";
        return dt;        

(Code snippet is taken from Tess’ Buggy Bits demo application for her Debugging Labs – see: http://blogs.msdn.com/b/tess/archive/2008/02/04/net-debugging-demos-information-and-setup-instructions.aspx)

And you are storing that DataTable in a session:
Session["AllProducts"] = DataTools.GetAllData();
Again...Storing big data in session objects is BAD. I just use this approach for showing the differences between the compression enabled and disabled for session objects.
I will simply use TinyGet from IIS Resource Toolkit to create load on my test application.

The following command will make HTTP request to
http://ServerName/default.aspx for 100 times simultaneously:

tinyget -srv:ServerName -uri:/default.aspx -loop:100

Although the best is to use Performance Counters, I will use Task Manager to compare the results.

Here is the task manager output for the compression disabled:

...and here is the output for the compression enabled:

As you can see the memory usage of the aspnet_state.exe process is decreased dramatically. This would also help a lot if the sessions are stored in another machine because you would send less data in network.

Although memory usage is less when compression is enabled, there is one thing to pay attention: you might see higher CPU usage on the web server as GZip would be used to compress and de-compress the session data on the server.


For a great article article about how useful enabling compression when the sessions are stored in SQL Server is, please go to the following blog post:

Asp.Net 4.0 - Session State Compression



ASP.NET Session State Overview

Compress session state in ASP.Net 4.0

Applies To



Comments (1)
  1. Fatih Durgut says:

    Great article, thank you for sharing us.

    One question. Is is possible to share CPU usage on IIS at both version(compress enabled and disabled). I'm wondering how CPU is effected from compression.


Comments are closed.

Skip to main content