I have a Asp.net/C# web Application hosted under IIS7.5 server 2008 64bit. my application build is 32 bit. The viewstate of my pages are very large (1mb to 4mb). the problem that i am seeing is that when i keep using the website for a period of time the Memory usages of the browsers keeps growing upto 50 MB. i am not sure where should i start looking for the problem. i have ScriptManger in my master page and proxy on my child pages not sure if it contributes to this? and where the problem could be, any help would be appreciated.
-
To find a memory leak, take a look at these suggestions: http://stackoverflow.com/questions/5028479/finding-memory-leaks-in-javascript-using-firebug. – Garrett Vlieger Nov 22 '11 at 19:23
-
150 MB is not that much for a browser. You should worry more about your viewstate size. 4MB viewstate means the client needs to send and receive all 4 MB for each request. A lot of people is still on asymmetrical DSL which typically have relatively low upload speeds. This means that each request to your application likely feels very slow to many of your users. – driis Nov 22 '11 at 19:26
-
the problem i am seeing is my server response time is in avg of 0.87 sec but avg client response time is 12 sec for intranet users with network delay of less that 10 ms. my guess is that the memory leaks that i am seeing might have somethign to do with this issue. – Natasha Thapa Nov 23 '11 at 02:26
-
We don't know details of your application but 4MB of Viewstate is out of the ordinary and will not typically perform well. Can you give us more details about what is wrong with the site and how the site is architected? – Chris Porter Nov 23 '11 at 06:30
2 Answers
The viewstate is just a hidden field in the HTML is POSTed to the server when the is submitted on the page. The client saves the posted data for a session so that it can reply/repost it on request (i.e. the user does a back and then a forward, it will prompt the user to resubmit the form/post data).
you might be able to trick the browser into not saving the data by setting the max-age
in the response header to 0 and setting the cache-control
to not cache.
HOWEVER, as pointed out in the comments, a viewstate >1MB is not a desirable situation to be in. You would be better storing client data in the server side Session
.
There is a couple of things that you could do as a quick fix.
1) Disable the ViewState
in client controls that don't need it.
http://msdn.microsoft.com/en-us/library/system.web.ui.page.enableviewstate.aspx
or
<asp:AnyControl EnableViewState="false"/>
2) Enable the trace for the application to see where it is being used disable accordingly/find the leak. http://msdn.microsoft.com/en-us/library/wwh16c6c.aspx

- 1,693
- 13
- 19
Your issue is that you're storing too much on the client side (viewstate or cookies). For each request the user makes their browser is uploading this to your web server. So, even though the web server can process the request quickly it takes a while for the 4MB request to be uploaded to the server. This isn't a memory leak. It is a flaw in your logic in regards to how much you store on client's browser. Perhaps on each page load you are adding the same large data to the client's viewstate or cookies so after a while the requests get so large that the wait time becomes noticeable. To determine the problem you need to monitor viewstate and cookies for each page request from one client and see exactly what grows and then you should be able to identify the cause.

- 2,972
- 1
- 20
- 18