(Viewstate) Size (really) matters 34ft5#4

Last november I blogged in detail on reducing the viewstate size of a page with a dtagrid or a datalist. This week I saw the app concerned in its production environment. It was a cripple duck, now it is a swift. Yep, size does matter.

blog on, Peter

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/blogs/peter.van.ooijen pvanooijen

    You can influence the size of the viewstate by disabling it for controls which don’t need it. Watch out when doing that, disabling a control’s viewstate will also disable the viewstate of the controls owned by the control (up the tree).

    I havn’t heard of this proxy server thing yet. If so, it will depend on the proxy server, so it’s out of your app’s control.

  • dgoyani

    I have heard that when viewstate reaches a limit, proxy servers tend to truncate it. I would like to know how can I set that size OR which factors decide upto what size proxy server would allow without any alter.


  • Peter van Ooijen

    Scott, compressing is cool, it will save on the precious bandwitch.

    But my main point is that you don’t need the viewstate at all for most controls. Default it is switched on, one of the fisrt things you should do after dropping a control on your form is disable the viewstate.

  • Scott Galloway

    Hi, you can also compress ViewState – I made a start on this here: http://www.mostlylucid.co.uk/posts/694.aspx

  • Adam Weigert

    ViewState is a great tool that people shouldn’t be afraid of. In cases where the ViewState is rather large and its not feasible to send the information to the user and you do not want to re-query the data source (maybe because it takes longer than desired) you can inherit from System.Web.UI.Page and overload the methods associated with loading/saving ViewState and have it stored in a database much like the Session state in SqlServer mode.

    The way I did it was to register a new hidden form field called __VIEWSTATEGUID that had a GUID value that would identify the row in the database. I also allowed for a TimeOut of the ViewState information. So you could set it per page if you needed.

    I have seen production applications go from slow and bulky page responses to super quick and speedy. The two extra round trips (load/save) is not even noticable. I would suggest you research this further as a viable solution to ViewState bloat.