(untagged)

C# ViewState Management/Storage - Four Locations!

xbadenx

0.00/5 (No votes)

5 Nov 2007

In this article, I discuss the PageStatePersister, and detail ViewState storage in one of four locations: Session, Application, AppGlobals, and server Cache.

Download StaticAppGlobalsAppGlobals.zip - 3.4 KB

Introduction

From an SEO standpoint, page size matters, as well as the location of text on your page. When creating a site with VS .Net, we end up with a ViewState variable, which in some cases, can take up a whole lot of space near the top of the page. This could, in fact, dilute the contents' importance on a given web page. In terms of page size, some search engines only cache the first 120kb of data.

This project was an attempt at finding another location to store the ViewState. In this case, I made four locations available for storage:

Session
Application
AppGlobals
Cache

This can be easily implemented in any C# project by creating a base class, referencing it in all classes, and selecting the storage location in an appSettings key in the Web.config. What is missing, however, is a SQL Server storage location. I'd be quite willing to incorporate at any such implementations!

Before fully diving into the code, I'd like to first discuss why it's important, and how the PageStatePersister, really didn't help.

Background

Enter the importance of reducing the ViewState parameter size. My initial reason for writing this code/putting it together, are a bit different that Oleg Sobol's in this (ViewStateProvider_Net2_0.asp) article, but I think are just as applicable, but our core reason is the same � ViewState size � it does matter.

Unfortunately it's been a while since I wrote this internal article, and haven't fully referenced all the sources. So if I've used some of your code, I apologize in advance.

ASP.Net ViewState Management

I tested using no ViewState management, ASP.Net 2.0's PageStatePersister, and the server caching method.

My overall results show that the server caching method is superior to the others. In some cases, the payload of the PageStatePersister is about equal to that of the server cache method, but on pages that contain a higher number of server controls, the PageStatePersister falls dramatically short of the server cache method (see Login.aspx below).

Server caching offers four ViewState stores - session, application, appglobals, cache. For testing purposes I only used server caching, as the data below reflects it is the superior method.

It is my conclusion, based on this and the benchmark tests located at http://www.eggheadcafe.com/articles/20040613.asp, that we use the server cache method.

ViewState test without the server-side scheme is in the first column; the four server side schemes follow:

	VIEWSTATE WEB STRESS COMPARISON
TEST NAME	VIEWSTATE	SESSION	APPLICATION	CACHE	GLOBALS
NUMBER OF HITS	3322	18483	18476	20170	16723
REQUESTS /SEC	27.64	153.8	153.74	167.84	140.32
TOTAL BYTES REC'D (KB)	68016.63	22923.25	22977.13	25074.51	20798
PERCENT DIFFERENCE	N/A	456.44%	456.22%	507.24%	407.67%

Regarding the server stores method, I've used the same design pattern myself � first routing data through a base class � very slick.

I've created an assembly containing the ViewState handler, which I can import into any future projects that use these classes. Once again � write once, use anywhere. I also converted some of the code for better usability with 2.0.

Test results below:

Default01.aspx

No Viewstate Management: ~ 329 characters | Payload: 1k

PageStatePersister: ~ 129 characters | Payload: < 1k

Server Cache Viewstate Storage: ~ 140 characters | Payload: < 1k

No Viewstate Management: ~ 349 characters | Payload: ~ 1k

PageStatePersister: ~ 149 characters | Payload: < 1k

Server Cache Viewstate Storage: ~ 141 characters | Payload: < 1k

No Viewstate Management: ~ 1345 characters | Payload: ~ 2k

PageStatePersister: ~ 1353 characters | Payload: ~ 2k

Server Cache Viewstate Storage: ~ 141 characters | Payload: < 1k

Managing the ViewState

The solution is to create a base class to manage the Viewstate.

Create an Assembly called StaticAppGlobals where three files will reside:

AppGlobal.cs
BasePage.cs (this is your base class that will be inherited in all classes)
viewStateSvrMgr.cs

Setting the ViewState Storage Location

We can select to store the ViewState in one of several locations:

Session
Application
Appglobals
Cache

Selection of the receptacle is done in the web-app's Web.config file:

<appSettings>
    <add key="ServerSideViewState" value="true"/>
    <!--ViewStateStore: session|application|appglobals|cache-->
    <add key="ViewStateStore" value="cache"/>
</appSettings>

Using the Base Class

Since each class needs to inherit System.Web.UI.Page we will inherit this from our base class, and inherit our base class in all classes:

Instead of :

public partial class Default : System.Web.UI.Page
{
    ... 
}

The definition of our class now becomes:

using StaticAppGlobals;  // viewstate management uses BasePage

public partial class Default : BasePage
{
    ... 
}

Now, since all pages must inherit Page, the base class inherits this:

namespace StaticAppGlobals
{
    public class BasePage : System.Web.UI.Page
    {
        ...
    }
    
    ...
}

... and now, you're off to the races, with C# ViewState management!

Points of Interest

While using the Server Cache method on a heavily-visited site without proper cache management, a server crash can be experienced, so the other methods would be preferable.

I haven't had a chance to work on a SQL implementation, but would love to see one added to this.

I've added this to several projects I've created. One, gave administrators the options to select the storage location from a radio button list. Thus, no re-compiling and the change was instant.

History

None yet...

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here