0

I'm stuck with a problem that causes my WebApplication to crash on a regular bases. A Client (Browser) get the HTTP status code 500 after making some (more than 1) requests to the server. I turned on the IIS Failed Request Tracing and discoverd, that the request exceeded the max request limit:

Maximum request length exceeded

I looked at the hidden __VIEWSTATE field and found, that it contains some information I expected and a cryptic (probably base64 encoded) serialized object with 49,500 characters. I didn't know, why this was so large and Checked my Session and ViewState objectes in my code behind. But nothing was suspicious.

Since I'm displaying 2 ASP.NET Charts and a large data table (5k rows and aprox 20 cols) I went into my Web.Config file and increased my request limit to

</system.web>
  <httpRuntime maxRequestLength="4194304"/>    
</system.web>

That was kinda successfull, meaning that the server survived one more request bevore then crashing with an OutOfMemoryException, claiming there is no more memory available.

By now, I'm pretty sure that there are some (and with some I mean tons) unwanted, unneccesary, most likely unused objects stored. (nice way of describing a memory leak ;) ).

But at this point, I am lost. Is there any way I can look into the ViewState before its being serialized and check, what kind of objects are referenced there? Can I clear/delete/flush the ViewState/Session/whatever is responsible for this in order to have a clean serialized ViewState that does not exceed the default limit?

Chrisi
  • 371
  • 3
  • 15
  • Just how big is your page? The values of server controls are stored in view state by default (i believe), so unless you're disabling view state on the page level or on each individual control I could imagine it would grow... but hard to believe your view state could get that big. – Kritner Jul 14 '15 at 12:21
  • Have you tried to set EnableViewState="false" on your GridView Or DataTable if you do not need the viewstate – Nikolay Jul 14 '15 at 12:23
  • My Page contains 5 dropdown lists, 6 textboxes, 3 radiobuttons, 2 aps.net charts within an ajax toolkit tab container and a native HTML table rendered inside an asp:literal – Chrisi Jul 14 '15 at 12:34

2 Answers2

0

On server Side : We should code which can take care of response time for this we can follow these following things

1.Try to avoid ViewState : if you don’t need ViewState then Disable View state on page level. There are many levels of disabling of ViewState

Control level : we can disable ViewState for specific control

<asp:TextBox ID="TxtCustomerID" runat="server"  EnableViewState="false" />

Page level : we can disable view state of whole page

<%@ Page Title="Customer" Language="C#" EnableViewState="false" %>

Directory level : we disable view state on directory level, just add location tag under configuration tag in web.config, in following example I am disabling ViewState for Docs directory.

<location path="~/Docs">
     <system.web>
          <pages enableViewState="false"></pages>
     </system.web>
</location>

Website level : for disabling ViewState on website level, set enableViewState property false of pages tag under system.web tag in web.config

<pages enableViewState="false"></pages>

Used From : http://ianswerable.com/asp-net-performance-best-practice/

Nikolay
  • 329
  • 1
  • 7
  • But (I think) I need the Viewstate. I've got several DropDownLists that depend on another one. So I have put each one of them inside an UpdatePanel to change values. – Chrisi Jul 14 '15 at 12:37
  • try this for now to see if that is the problem. Is the data too big or the problem is from something else . – Nikolay Jul 14 '15 at 12:39
  • well you can try this site will help you to catch the exception http://stackoverflow.com/questions/665453/catching-maximum-request-length-exceeded – Nikolay Jul 14 '15 at 12:42
  • I already have overriden `OnError ` , i.e. implemented `Application_Error` and put some breakpoints into them. But they are not triggerd – Chrisi Jul 14 '15 at 12:55
  • Well Last thing from me : http://stackoverflow.com/questions/3853767/maximum-request-length-exceeded – Nikolay Jul 14 '15 at 13:04
  • Did that, resulted in an OutOfMemoryException – Chrisi Jul 14 '15 at 13:30
0

Finally found the reason. Apparently an also stores its content in the ViewState, which causes the PostBack requests to be ridiculously big. (Also had some legacy code that was pushing data into the ViewState)

Thea
  • 7,879
  • 6
  • 28
  • 40
Chrisi
  • 371
  • 3
  • 15