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.