With user controls on a page, I understand that every control has an impact on memory usage by storing their own state in ViewState. My question is, how much?
For example - I have a feedback form as a control on my masterpage. It is set to Visible="false" by default. A user clicks on a feedback button, and the control becomes visible while it's needed.
What would would be the relative performance impact by having control sitting there on everypage (as it's located in the masterpage), but not visible? The site I'm developing will potentially have large amounts of traffic and I wonder if I'm setting myself up for a headache later on if things become slow.
Thanks
Performance could be impacted on the server and the client. Primarily you want to reduce the amount of HTML including viewstate that is sent to the client. If this sits on every page then you will send this viewstate information more often than you really need to.
I think you should have some logic that ensures that the feedback form control is only added to the feedback page. Rather than use visible="false", put it on it's own page and link to it, or dynamically add the control to the page.
The main benefits will be reduced bandwidth usage, and faster rendering of the page on the client. Secondary benefits include easier debugging and cleaner code rendering to the client.
With all performance problems you should be testing performance and making judgments based on hard data. In this case work out the size of the viewstate on the client, then multiply by number of requests to see the size of bandwidth usage on the server. On the client use a tool like FireBug to understand the overall page size received by the client.
It depends on the control. Datagrid with hundreds rows might generate 100k of viewstate. On the other side, checkbox won't generate too much.
You can just drop your feedback form control on empty aspx page, visit it in the browser and check for __viewstate hidden field. This is how much will you feedback form will add to each page in terms of viewstate. Then you will have to decide if it is acceptable.
I wouldn't htink about such an optimizations right at the start. If it will become slow later on, you can always change the form to be pure html and use ajax or something to post it data to server. As long as it is user control and not copy pasted content it will be easy to optimize
Related
I have a page containing a large amount of controls that can trigger postbacks to the server. I know that it is not considered good practice to have a huge amount controls on one page, but the nature of my ASP.NET web application requires it. Seeing that I have a large amount of controls on this page, I make extensive use of UpdatePanels. I am storing ViewState in Session in order to reduce the response size of the page, which works beautifully.
However, with Fiddler I noticed that the 'asyncPostBackControlIDs' after the '__VIEWSTATE' part of the ajax response contains a list of every control of every UpdatePanel that can trigger a postback. This list is huge! It seems that this list doesn't change much per page, and thus it doesn't make sense to download the entire list every time a postback within an UpdatePanel occurs...
Is there any way to store the 'asyncPostBackControlIDs' on server like you can do with ViewState, or otherwise reduce the size of the 'asyncPostBackControlIDs' list?
AFAIK, there is no documented way for storing asyncPostBackControlIDs else where - further, I am very much in doubt if there can be such possibility because most probably those control ids would be required on client side to decide whether to do regular or asynchronous post-back.
You can set ChildrenAsTriggers property of UpdatePanel to false and register controls manually that are actually triggering the post-back - for example, you may have LinkButton/HyperLink that has java-script handler.
Further, perhaps you may able to reduce the list of controls that can cause post-back. For example, you can use anchors(a) instead of linkbuttons/hyperlinks and then set a hidden variable and then simulate a (hidden) button click. On server side, the value of hidden variable would indicate the actual control responsible for post-back. This way, you can have one button that is a post-back control for many other controls.
Finally, you are really a guy who want to have very efficient request/response streams then abandon ASP.NET control model and rather use ASP.NET MVC. Or at less scale, stop using Update Panels for AJAX (they do complete POST of page and almost entire page cycle is executed at server side) and use script services (along with jquery plugins) instead.
Lastly, you need to see the control ids size with the actual response size - for example, 5K long ids within 100K response may not be a large overhead. Reducing those ids would probably give you 5% savings (if possible) but are efforts for the same worth it?
I understand the use of View state. Any material that talks about view state, explains the need and use of it. However there is an option provided at every control level/ page level to disable it as well.
In what circumstances we might want to disable the viewstate of a page or control?
From an online material, I read that,
If the page doesn't have any dynamic data, data to be persisted
between round trips we can disable viewstate.
I agree to this statement, but what's the advantage of doing this? What do we get out of it?
Some pages have HUGE viewstates. As such it takes time to send back and forth, its more load on the server, more network traffic, etc. There's no need for it a lot of times, so your apps will be quicker by shrinking your viewstate.
Take note even fully disabling viewstate at times will generate still a small required viewstate because of control requirements, but it can be greatly reduced. I've seen viewstates go into 200kb per page.
You get less payload since the ViewState hidden value gets set to "". In datagrids displaying several thousands of records, the ViewState can become several MB in size
Performance is improved not only because the ViewState is not transferred anymore, but also because reading ViewState is typically an expensive operation since it involves decrypting it and deserializing the value.
Actually, you can improve performance just by disabling the encryption of the ViewState but this is not a good security practice.
As the page has to render the ViewState to the client it can speed up load times if the ViewState is disabled.
Around the time that .Net was introduced I remember trouble shooting a page that was loading slowly, the page was rendering a sizeable grid all of which was been saved into ViewState. Removing the data from the ViewState made a big difference.
ViewState is rendered as a hidden input field in the web page. This makes the page load more slowly, and also makes post backs slower, since the ViewState must be posted along with everything else.
Therefore, your page will perform faster if you disable ViewState. How much faster? Hard to say.
In general, if you don't need ViewState, disable it.
Note also that even if you disable ViewState, there will still be a hidden control with a small amount of data that is neccessary for .NET.
When I display info or error messages to the user as asp:Label or asp:Literal controls, I almost always set EnableViewState to false, because they almost always apply only to a given post-back. Setting EnableViewState to false means I never have to write this in my code-behind:
lblSomethingWentWrong.Text = string.Empty;
This is 10KB in my HTML source:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTEyOTAwODE4Nw9kFgJmD2QWAgIDD2QWBGYPZBYEAgEPDxYCHgdWaXNpYmxlaGRkAgIPZBYIAgEPFgIfAGdkAgMPDxYEHgRUZXh0BQNUb20eC05hdmlnYXRlVXJsBQt+L3VzZXJzL1RvbWRkAgUPFgIfAQUFMSwzMjZkAgcPDxYCHwIFCH4vTG9nb3V0ZGQCAg9kFgQCEA9kFgICAQ8WAh8BBXk8YSBhZGR0aGlzOmRlc2NyaXB0aW9uPSJTaGFyZSBTY2lycmEiIGFkZHRoaXM6dXJsPSJodHRwOi8vMTI3LjAuMC4xL3NjaXJyYW5ldy9ibG9nLzM5L3dlZWVlIiBjbGFzcz0iYWRkdGhpc19jb3VudGVyIj48L2E+ZAIUD2QWEAIBDxYCHwBnFgICAQ8WAh4EaHJlZgUifi9BZG1pbmJsb2cuYXNweD9hY3Rpb249ZWRpdCZJRD0zOWQCAw8WAh8BBQ0xNyBBcHJpbCAyMDExZAIFDxYCHwEFBVdlZWVlZAIHDxYCHwEFDjxwPm9ya2dyZ3I8L3A+ZAIJD2QWAmYPZBYCAgMPFgIeC18hSXRlbUNvdW50AgMWBmYPZBYCAgEPDxYGHwEFBEJsb2ceB1Rvb2xUaXAFH090aGVyIHJlc291cmNlcyByZWxhdGVkIHRvIEJsb2cfAgULfi90YWdzL2Jsb2dkZAIBD2QWAgIBDw8WBh8BBQtDb25zdHJ1Y3QtMR8FBSZPdGhlciByZXNvdXJjZXMgcmVsYXRlZCB0byBDb25zdHJ1Y3QtMR8CBRJ+L3RhZ3MvY29uc3RydWN0LTFkZAICD2QWAgIBDw8WBh8BBQtDb25zdHJ1Y3QtMh8FBSZPdGhlciByZXNvdXJjZXMgcmVsYXRlZCB0byBDb25zdHJ1Y3QtMh8CBRJ+L3RhZ3MvY29uc3RydWN0LTJkZAILDw8WBB8CBQt+L3VzZXJzL1RvbR8BBQNUb21kZAINDw8WBB8CBRh+L2Jsb2cvMzkvd2VlZWUvY29tbWVudHMfAQULMTAgY29tbWVudHNkZAIPD2QWAmYPZBYGAgIPFgIfBAIKFhRmD2QWDgIDDw8WBB4IQ3NzQ2xhc3MFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQeBF8hU0ICAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yM1QxNzozNToyNC45MjAwMDAwIj4yMyBBcHJpbCAyMDExIGF0IDE3OjM1OjI0PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQeCEltYWdlVXJsBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFoAM8ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPndlZiB3ZSBmIHdmZTwvZGl2PjxkaXYgY2xhc3M9ImNvbW1lbnQtcXVvdGVyIj5Db21tZW50IGJ5IDxzdHJvbmc+VG9tPC9zdHJvbmc+PGJyIC8+PGJyIC8+cGlsbHV1w7rDuiB0dCB0IGggdGggdGggdGggdGggdGg8L2Rpdj48ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPnBpbGx1dcO6w7ogdHQgdCBoIHRoIHRoIHRoIHRoIHRoPC9kaXY+PGRpdiBjbGFzcz0iY29tbWVudC1xdW90ZXIiPkNvbW1lbnQgYnkgPHN0cm9uZz5Ub208L3N0cm9uZz48YnIgLz48YnIgLz5waWxsdXXDusO6IHR0IHQgaCB0aCB0aCB0aCB0aCB0aDwvZGl2PmQCAQ9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjNUMTc6Mjk6MjkuMjQ3MDAwMCI+MjMgQXByaWwgMjAxMSBhdCAxNzoyOToyOTwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUyPGRpdiBjbGFzcz0iY29tbWVudC1xdW90ZXIiPnJlZ2c8L2Rpdj53ZWYgd2UgZiB3ZmVkAgIPZBYOAgMPDxYEHwYFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQfBwICZBYEAgEPFgIfAQVaPGFiYnIgY2xhc3M9InRpbWVhZ28iIHRpdGxlPSIyMDExLTA0LTIzVDE3OjI4OjIzLjM2NzAwMDAiPjIzIEFwcmlsIDIwMTEgYXQgMTc6Mjg6MjM8L2FiYnI+ZAIDDw8WBh8CBQt+L3VzZXJzL1RvbR8FBR5WaXNpdCB0aGlzIGdhbWUgbWFrZXJzIHByb2ZpbGUfAQUDVG9tZGQCBQ8PFgQfAgULfi91c2Vycy9Ub20fBQUgVG9tIG1ha2VzIGdhbWVzIHdpdGggQ29uc3RydWN0IDJkFgJmDw8WBB8IBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFH1tRVU9URV1yZWdnWy9RVU9URV13ZWYgd2UgZiB3ZmVkAgMPZBYOAgMPDxYEHwYFGWNvbW1lbnQtaGVhZCBjaC1oaWdobGlnaHQfBwICZBYEAgEPFgIfAQVaPGFiYnIgY2xhc3M9InRpbWVhZ28iIHRpdGxlPSIyMDExLTA0LTIzVDE3OjI3OjU1Ljk1NzAwMDAiPjIzIEFwcmlsIDIwMTEgYXQgMTc6Mjc6NTU8L2FiYnI+ZAIDDw8WBh8CBQt+L3VzZXJzL1RvbR8FBR5WaXNpdCB0aGlzIGdhbWUgbWFrZXJzIHByb2ZpbGUfAQUDVG9tZGQCBQ8PFgQfAgULfi91c2Vycy9Ub20fBQUgVG9tIG1ha2VzIGdhbWVzIHdpdGggQ29uc3RydWN0IDJkFgJmDw8WBB8IBUlodHRwOi8vd3d3LmdyYXZhdGFyLmNvbS9hdmF0YXIvNTI3MWQzMjgzZGI5NTdlZjNhODY3NjFlZDE1YzE2OTY/cj1wZyZzPTgwHwUFDlRvbSdzIEdyYXZhdGFyZGQCBw8PFgYfBgUQcyBjb21tZW50LXJlcG9ydB8FBRBSZXBvcnQgdGhpcyBwb3N0HwcCAmRkAgkPDxYGHwYFEHMgY29tbWVudC1kZWxldGUfBQUQRGVsZXRlIHRoaXMgcG9zdB8HAgJkZAILDw8WBh8GBQ5zIGNvbW1lbnQtZWRpdB8FBQ5FZGl0IHRoaXMgcG9zdB8HAgJkZAINDw8WBh8GBQ9zIGNvbW1lbnQtcXVvdGUfBQUPUXVvdGUgdGhpcyBwb3N0HwcCAhYCHwMFBSNQb3N0ZAIPDxYCHwEFdDxkaXYgY2xhc3M9ImNvbW1lbnQtcXVvdGVyIj5Db21tZW50IGJ5IDxzdHJvbmc+VG9tPC9zdHJvbmc+PGJyIC8+PGJyIC8+T2sgbmljZSBvbmUgOi0pIExvdmluZyB0aGlzITwvZGl2Pk5vIHByb2JsZW1vZAIED2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yM1QxNzoyNzoyNy45ODcwMDAwIj4yMyBBcHJpbCAyMDExIGF0IDE3OjI3OjI3PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBXA8ZGl2IGNsYXNzPSJjb21tZW50LXF1b3RlciI+Q29tbWVudCBieSA8c3Ryb25nPlRvbTwvc3Ryb25nPjxiciAvPjxiciAvPk9rIG5pY2Ugb25lIDotKSBMb3ZpbmcgdGhpcyE8L2Rpdj5UaGFua3MhZAIFD2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQxNDozOToyMy4xMjAwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDE0OjM5OjIzPC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBR90cmhoIHJ0aCAgcnRocmhoIHRyIGhydCBocnQgcmh0ZAIGD2QWDgIDD2QWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQwMDozOTozNC45NDAwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDAwOjM5OjM0PC9hYmJyPmQCAw8PFgYfAgURfi91c2Vycy9DaGVlc2VCb3kfBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFCUNoZWVzZUJveWRkAgUPDxYEHwIFEX4vdXNlcnMvQ2hlZXNlQm95HwUFJkNoZWVzZUJveSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyL2ZjMjE2Nzc4ZjYzOGM4N2FmODZhNjI0MWNhMzZiM2EyP3I9cGcmcz04MB8FBRRDaGVlc2VCb3kncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBTFMb3ZpbmcgdGhpcyBibG9nIHBvc3QgdGhhbmtzIGZvciBpdCwgKzEhICBHbCBsb2whZAIHD2QWDgIDDw8WBB8GBRljb21tZW50LWhlYWQgY2gtaGlnaGxpZ2h0HwcCAmQWBAIBDxYCHwEFWjxhYmJyIGNsYXNzPSJ0aW1lYWdvIiB0aXRsZT0iMjAxMS0wNC0yMlQwMDoxMzowNC44NTMwMDAwIj4yMiBBcHJpbCAyMDExIGF0IDAwOjEzOjA0PC9hYmJyPmQCAw8PFgYfAgULfi91c2Vycy9Ub20fBQUeVmlzaXQgdGhpcyBnYW1lIG1ha2VycyBwcm9maWxlHwEFA1RvbWRkAgUPDxYEHwIFC34vdXNlcnMvVG9tHwUFIFRvbSBtYWtlcyBnYW1lcyB3aXRoIENvbnN0cnVjdCAyZBYCZg8PFgQfCAVJaHR0cDovL3d3dy5ncmF2YXRhci5jb20vYXZhdGFyLzUyNzFkMzI4M2RiOTU3ZWYzYTg2NzYxZWQxNWMxNjk2P3I9cGcmcz04MB8FBQ5Ub20ncyBHcmF2YXRhcmRkAgcPDxYGHwYFEHMgY29tbWVudC1yZXBvcnQfBQUQUmVwb3J0IHRoaXMgcG9zdB8HAgJkZAIJDw8WBh8GBRBzIGNvbW1lbnQtZGVsZXRlHwUFEERlbGV0ZSB0aGlzIHBvc3QfBwICZGQCCw8PFgYfBgUOcyBjb21tZW50LWVkaXQfBQUORWRpdCB0aGlzIHBvc3QfBwICZGQCDQ8PFgYfBgUPcyBjb21tZW50LXF1b3RlHwUFD1F1b3RlIHRoaXMgcG9zdB8HAgIWAh8DBQUjUG9zdGQCDw8WAh8BBRdlZyBlICBnIGdlIGcgZyBnIGcgZyBlZ2QCCA9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjFUMjM6MzA6NTAuNjMzMDAwMCI+MjEgQXByaWwgMjAxMSBhdCAyMzozMDo1MDwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUcT2sgbmljZSBvbmUgOi0pIExvdmluZyB0aGlzIWQCCQ9kFg4CAw8PFgQfBgUZY29tbWVudC1oZWFkIGNoLWhpZ2hsaWdodB8HAgJkFgQCAQ8WAh8BBVo8YWJiciBjbGFzcz0idGltZWFnbyIgdGl0bGU9IjIwMTEtMDQtMjBUMDA6MDE6NDcuNjY3MDAwMCI+MjAgQXByaWwgMjAxMSBhdCAwMDowMTo0NzwvYWJicj5kAgMPDxYGHwIFC34vdXNlcnMvVG9tHwUFHlZpc2l0IHRoaXMgZ2FtZSBtYWtlcnMgcHJvZmlsZR8BBQNUb21kZAIFDw8WBB8CBQt+L3VzZXJzL1RvbR8FBSBUb20gbWFrZXMgZ2FtZXMgd2l0aCBDb25zdHJ1Y3QgMmQWAmYPDxYEHwgFSWh0dHA6Ly93d3cuZ3JhdmF0YXIuY29tL2F2YXRhci81MjcxZDMyODNkYjk1N2VmM2E4Njc2MWVkMTVjMTY5Nj9yPXBnJnM9ODAfBQUOVG9tJ3MgR3JhdmF0YXJkZAIHDw8WBh8GBRBzIGNvbW1lbnQtcmVwb3J0HwUFEFJlcG9ydCB0aGlzIHBvc3QfBwICZGQCCQ8PFgYfBgUQcyBjb21tZW50LWRlbGV0ZR8FBRBEZWxldGUgdGhpcyBwb3N0HwcCAmRkAgsPDxYGHwYFDnMgY29tbWVudC1lZGl0HwUFDkVkaXQgdGhpcyBwb3N0HwcCAmRkAg0PDxYGHwYFD3MgY29tbWVudC1xdW90ZR8FBQ9RdW90ZSB0aGlzIHBvc3QfBwICFgIfAwUFI1Bvc3RkAg8PFgIfAQUgcGlsbHV1w7rDuiB0dCB0IGggdGggdGggdGggdGggdGhkAgYPZBYCAgEPDxYCHglNYXhMZW5ndGgC9ANkZAIIDw8WAh8AaGRkZAx0/0RvMYX4SKMMjV5pXc+cjNqDEEepI0JWzIxpxOzG" />
This represents ~50% of the entire size of the page.
Why does it do this, why so long? Can I do anything about it? It's bad for mobile users.
What is this view state anyway and how to mitigate its size
In Asp.net WebForms every control saves its state because HTTP protocol is stateless and Asp.net WebForms pages bypass that by saving every control's state in this Base 64 encoded string. This is the only way for Asp.net framework to know whether some control's value has changed or not. But... This automatically means that static controls that don't get POSTed back to server (like label for instance) don't need to save their state. You can always set their EnableViewState="false".
Unfortunately this can't be set without any other code changes on other controls, that do get POSTed back (every server-side control that renders some sort of an input in HTML). This basically means that setting EnableViewState="false" on page level (within #Page directive) will have consequences that are seen as controls loosing their values, controls not firing certain events etc.
So, the more server-side controls you have the larger it will get (without turning it off on certain controls).
But I wouldn't worry if its size is 10k. That will go back and forth rather fast and painless. You will have problems when it gets much larger. I once worked on a project and we had an issue with a certain page (done by less experienced developer) where view state grew over 1MB. Imagine that. What a slowdown!
How to turn it off completely on page level
When you turn view state off on page level you have to be aware that certain controls that were loaded (or better said data bound) in on of your page's events, will have to be reloaded each time your page gets POSTed back at server. Otherwise they will show up as empty when your page gets back to the client.
Your server controls are filling the ViewState with data they will need on postback. If your page does not postback you can just disable the ViewState for the page.
To disable ViewState for the page you can just add EnableViewState="false" to the #Page directive. Please be aware you should only use this as a solution if you are 100% sure the page does not postback.
You also might want to check this MSDN article to get a better idea of what the ViewState does.
Disable viewstate for static controls, like a gridview.
Check out this question for more info:
If you are concerned about the viewstate on the client side, then think about storing it on the server side. Perhaps in a session variable. Take a look at this article as there is statistical comparison given. Download the solution and check out how to store it on the server side.
An Analysis of Keeping ViewState out of the Page
This article explained it neatly to me in the past: Taking a Bite Out of ASP.NET ViewState.
Basically viewstate's on by default and, depending on which controls you use, it can get out of hand pretty fast. Especially data controls like the gridview are responsible for massive injection of viewstate. You can disable that on a per control basis by setting the EnableViewState property to false. Be careful however as taking out viewstate might also take out functionality of the controls. So do it one by one and test test test.
Another way, and likely better for mobile, is to make use of ASP.NET MVC instead which doesn't have to deal with automatic viewstate injection.
Does anyone have any ideas or references they could point me to regarding optimizing the viewstate of my ASP .NET application? I don't want to turn it off all together, and the main goal of optimizing it is to speed up performance so I don't want to run an expensive function to recursively disable the viewstate for certain controls because that function would slow down the load time of the page which would defeat the purpose.
Any ideas?
Here are some ideas how you can optimize the size of ViewState transferred over the wire (copied from this answer):
Disable ViewState for controls that do not need it (this is the most effective solution). E.g. if you can cache some data on the server, then you can re-bind any databound controls with every request and it's not needed to save everything in ViewState.
Turn on HTTP compression on the server (IIS). This reduces the size of the page sent to the client, including the ViewState.
Compress the ViewState. This has an additional advantage over HTTP compression: it also reduces the size of PostBacks (data sent back to the server), since the ViewState is always sent back to the server during a PostBack. There are various approaches for this, e.g. as shown in this blog post.
Store the ViewState on the server instead of sending it in a hidden field with the page. The easiest way to do this is to use the SesionPageStatePersister, but there are other solutions which store the ViewState to disk instead of using the Session (see here for example).
There's not a lot I can tell you except "don't put a lot into your ViewState".
Places I'd look for optimizations:
Anything you added to ViewState yourself
Large amounts of data bound to data display controls like GridViews, <x>Lists, and Repeaters.
GridViews are particularly bad about ViewState; everything you databind goes into it, so if you bind a particularly large list expecting ASP.NET to handle pagination of it for you, you're going to have a huge ViewState. The only way to get around this is to only bind one page at a time to the GridView, but that means you'll have to do data-side pagination which can be just as painful, or to turn off ViewState for the GridView, which means (arguably) useful features like in-line editing are no longer available.
There's no silver bullet here.
ViewState is a client side state management and becomes part of your Request and Response packets and heavy viewstate can indeed slow down your application performance. One quick option to optimize ViewState performance is to keep it on the Server side and use it only when it is needed. This makes sense as ViewState is never really used on client browser end and is always needed on Server side when you Post-back. You can use a Distributed caching system such as AppFabric or NCache to store your ViewState on server side and this should help improve performance.
I have personally worked with NCache which has a no code change provider for ViewState caching.
Click here to view the article for ASP.NET View State Caching
I'm investigating an asp.net web application that extensively uses User Controls on each page. Most pages contain around 10-20 user controls. The User controls seem to be the visual representation of the business objects (if that makes sense), although at a finer granularity such as each tab of a tab control having its contents in a user control. The project itself has over 200 user controls (ascx files).
The performance of the application is very poor (and the reason I'm investigating). Each event (such as a click or dropdown selection etc) requires about 5 seconds for the page to load (10 seconds whilst in visual studio). The application has no use of Ajax.
Tracing is painful as the aspx pages themselves have no code in the code-behind as the user controls look after all of this, so tracing a single page requires trace statements in all the user controls that are on that page.
I actually think that having each user control look after its business code and being re-usable is a smart idea, but is an excessive use of user controls going to incur a performance hit? Does this seem like the structure of an asp.net application that was written by someone with a strong WinForms background?
EDIT
thought I should add that i'm not questioning the use of user controls (or even the amount) but simply whether having so many on a page that all accomplish things (each user control connects to the database for example) will generally cause performance problems...For example, if just one user control postsback to do something, what about the processing of all the others, some are visible and some aren't...#David McEwing mentioned that he had 40 optimised user controls performing etc, but if the developer was WinForms based or "not familiar with asp.net", then how are they going to make sure each one is optimised...
EDIT2
After getting a sql statement trace, the same calls for data are being executed 5-6 times per page call for each event as the different user controls require data that is not stored commonly e.g. each user control in the tab (mentioned above) makes the same call to populate an object from the database...I'm really not here to accuse user controls of being the problem (should i delete the question?) as clearly the problem is NOT user controls but with the use of them in this particular case...which I believe is excessive!
10-20 (or even hundreds) User Controls alone is beyond trivial. The presence of the controls themselves, and the idea of encapsulation, is definitely not the source of your problems.
It's impossible to say precisely what the problem is without actually profiling the application of course, but based on my experience I can say this:
What is more likely is the specific implementation of the business logic inside each user control is poor. With postbacks taking as long as you describe, each control probably looks back to your DAL for its own data on each request. This can be mitigated by two things:
Make sure user controls cache all their data on first load and never re-load it unless explicitly instructed to (usually by an event from a lower-level service)
Ensure the controls all use a set of common services which can reuse data. E.g. if two controls need access to the customers list, and they are executing in the context of the same request session, that should only require one customer list lookup.
I'll put myself firmly in the camp of folks that suggest there is no hard limit to a number of user controls that should be used on a page. It sounds like application-wide tracing is in order here instead of page-level tracing. It may very well be that a handful of these controls is causing the problem. Heck, it could be a single control causing all the fuss. However, since it's impossible to make any assumption about the level of resource-usage that the "average" (if there is such a thing) user-control takes up, it's likewise impossible to suggest a limit. Otherwise, we'd be able to come up with similar limits to the number of members to a class or the number of stored procedures to a database.
Now, if we're talking about 20 complex user-controls that are each retrieving their own data with each refresh and each with a bunch of sub-controls using ViewState whether needed or not, then yeah, that's a problem. Still, it has more to do with overall design than with there being too many controls. If, on the other hand, they've created a common user control to act as nothing more than the composite of a label to the left of a textbox (or maybe even every combination of label + user-actionable control) and have sprinkled this control throughout the app, I can imagine that you'd get a bunch of these on a page and I can't see why that would necessarily hurt anything.
I take it that you are not familiar with applications which use so many user controls?
It sounds like you may be jumping to the conclusion that this unfamiliar aspect of the application is the cause of the unfamiliar bad performance. Instead of making assumptions, why not try one of the following profiling tools, and find out:
JetBrains' dotTrace
Red-Gate ANTS
Automated QA's AQTime
These can all do memory and CPU profiling of ASP.NET applications.
I believe that one of the key purposes of UserControls is code reuse. That is, if the same functionality occurs on multiple web pages, then it is better to create a UserControl for it. That not only saves the developer from writing (or copying and pasting) the same code to several web pages, but it also makes maintenance much easier. Any change made to the UserControl is implemented automatically everywhere the UserControl is used. The maintenance developer doesn't have to worry about finding all the different places that the code needs changing.
I'm not sure if a single-use UserControl is as effective. They do encapsulate and segreate the code, which is nice on a busy web page.
Can you ascertain whether your UserControls are reused, or are many of them only used once.
I agree with Saunders about doing some profiling to determine the impact certain things have.
Note that you can get some free stress-testing tools for IIS here: http://support.microsoft.com/kb/840671
I will say, though, that having too many controls is probably not a good thing, IMHO. Without knowing more, I'd tentatively say 20 is too many.