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.
- Protected Overrides ReadOnly Property PageStatePersister() As PageStatePersister
- Return New SessionPageStatePersister(Me)
- End Get
- 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.
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:
- The internet connection at the client site
- Number of postbacks
- 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.
I recently had to upgrade an ASP .net 1.1 solution to .net 3.5. The website had a form where a user had an option to upload a file.
The ‘File Name’ is a read only textbox.
- <asp:TextBox runat="server" ID="txtFileName" ReadOnly="true" />
To get around this issue, remove the ReadOnly attribute from the textbox and add the readonly attribute in code.
- txtFileName.Attributes.Add("readonly", "readonly")
Cassini is a simple web server provided by Visual Studio. I tried using it on several occasions, but it always resulted in a bad outcome. I found that it works great for small simple projects, but once the complexity of your project grows Cassini doesn’t hold up. As I develop, my application would randomly stop working with the following error:
Type is not resolved for memeber ‘Member.Type, Library.Name, Version=126.96.36.199, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxxx’.
There are several solutions for this on the web, but the best way to fix this error is to set up your ASP.Net application in IIS. After setting up the site in IIS, change the properties of your website to use IIS.
Following are the steps to do this (for VS2008):
1. Right click the website in the solution explorer and select ‘Property Pages’
2. Select ‘Start Options’
3. Select ‘Use custom server’ and specify the ‘Base URL’
In conlusion, I think that Cassini is a great alternative if you don’t have IIS. If IIS is available, set up your site in IIS and save yourself a headache!