ASP .NET Postback Performance – Part 2

In my previous post I described a performance issue I ran across due to a large amount of ViewState.  Now I will discuss some possible solutions.

To fix this issue I decided to store the ViewState in the Session, by overriding a PageStatePersister property to return SessionPageStatePersistor. The default page state persister is a HiddenFieldStatePersister, which stores ViewState as a hidden Base64-encoded string on the page.  To read more about the PageStatePersister, see the following MSDN documentation.

Code Snippet
  1. Protected Overrides ReadOnly Property PageStatePersister() As PageStatePersister
  2.     Get
  3.         Return New SessionPageStatePersister(Me)
  4.     End Get
  5. End Property

This functionality can be implemented as needed for each page.  I implemented above code only for the few pages that were performing poorly and got the following results:

    • From 143K per postback to 13k per postback
    • From 188K per postback to 2k per postback
    • From 700k per postback to 1k per postback
    • From 244K per postback to 1k per postback

To implement this functionality application wide, override PageStatePersister in the base class for all your pages.  This does place a larger load on the web server, so make sure that this is a right solution for you.

As a long term fix, I plan on going through the screens and disabling ViewState for controls that don’t need it. Since majority of controls do not need ViewState enabled, this should minimize the size of the ViewState.

ASP .NET PostBack Performance – Part 1

I ran into a performance issue with an ASP.Net website that was experiencing a slow down on some of the data heavy screens.  I was not able to recreate this performance issue from my office, but it was very noticeable at the client site.  The pages that were extremely slow were doing a significant number of postacks within AJAX Update Panels.

After some research, I was able to narrow down the cause of this issue to be related to the following:

    1. The internet connection at the client site
    2. Number of postbacks
    3. Size of the ViewState

I was able to rule out the performance of the SQL Server and the Web Server since I was not able to reproduce the issue from my office. 

After testing the bandwidth at the client site, it appeared that their upload bandwidth was low and highly utilized.  The application was doing several postbacks on most utilized screens.  The AJAX Update Panel enhanced user experience by doing partial updates to the screen, therefore minimizing the flicker, but it also caused performance issues since each request to the server was a full ASP.Net postback.

To determine the size of each postback I used a Fiddler to record my HTTP traffic.  Fiddler can be downloaded for free here

After recording the traffic, I looked at the “TextView” of the request in Fiddler to determine the size of my postback. I did this for all slow performing screens. The size of the postback for each of the slow performing screens was as follows:

    • 143K per postback
    • 188K per postback
    • 700k per postback
    • 244K per postback

These are fairly large and can eat up the upload bandwidth quickly.  At this point I could either re-work these screens to eliminate these postbacks or find a way to minimize the size of my ViewState on these pages.

I will discuss my solution to this issue in the Part 2 of this post.