VIEWSTATE Makes Page Huge, Can I Disable It?

[mickers]

The VIEWSTATE size is killing our apps and it keeps growing. The .aspx files are bigger than 2.5Mb in some cases.

The developer is on vacation and I just installed a 90 day trial of VS 2008 to test turning form-level VIEWSTATE off then turning it on again to see if the VIEWSTATE gets reduced substantially. It didn't. It went right back to the same size.

When VIEWSTATE was off the page size was 650K. With it off I tested changing one combo field and it worked. The problem is that some pages are complicated with grids and custom user controls, so I am sure that disabling it can possibly affect whether some of these fields work at all. Is this true?

Our server is Win Server 2008 Enterprise.

Any ideas to reduce the size of VIEWSTATE and keep the app running? I need to get this fixed today.

This is an extremely important app that people across the US are using, and any help is greatly appreciated.

http://www.21stsoft.com

http://www.mercuryleads.com

 

[jmeckley]

yes, viewstate is a pain point with webforms. you cannot disable it completely, but you can take steps to reduce it's footprint. there isn't a quick fix that will solve this, but there are some techniques you can use to limit it's foot print.

1. disabling viewstate. this will reduce the size of viewstate. but it also has an impact on how webforms works, so you will need to do a full test of the system if you disable viewstate. you can disable view state at the control, page and site level.

2. reduce the number of webserver controls. the more <asp:...> tags and runat="Server" attributes on an aspx the larger viewstate will be. replacing webserver controls with standard html dom elements will also help.

3. limit the result sets for paged data. if the webform uses gridview, listview, formview, etc and paging is enabled the entire result set is serialized to viewstate, even though you are only displaying a subset of records. for example a list of customers. you may display 20 at a time, but the datasource queries all customers and binds them to the grid. viewstate will contain all the customers, not just the 20 that are displayed.
another example of this is dropdown lists. if you have a large list all that information is stored in viewstate.

the solution to this problem is paging the data at the database level, not the view.

4. create smaller forms and provide the user with a "click next" experience for completing tasks. the size of each page will be reduced thus improving throughput.

5. don't use webforms. use an MVC framework instead. this is the most extreme solution, but it should be said. webforms really is an odd-ball framework for web development. an MVC framework aligns much better with the concepts of http and a stateless environment. this is a paradigm shift and making this transition will be huge, especially if the devs have never seen MVC before.

6. user acceptance and stress testing. if this is a nation wide website, internal or external, you need an testing environment to verify the system before deploying to production. testing locally in Visual Studio is great for the developer, but it means nothing for production.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[mickers]

Jason,
Many thanks for the detailed and thoughtful response.

Sounds like I'm going to have to wait for the developer to get back on Wednesday for a resolution.

I was hoping for a temporary fix that could get us up and running in the short-term.

http://www.21stsoft.com

http://www.mercuryleads.com