Asp.Net ViewState性能(Asp.Net ViewState performance)

Asp.Net ViewState性能(Asp.Net ViewState performance)

我是Asp.Net的新手。 我有一个关于viewstate控件的问题。 Msdn表示它是一个客户端状态管理，但建议如果由于性能问题导致页面上有大数据，则可以禁用它。

因此，如果这是客户端状态，它如何影响网站的页面加载时间？

I am new to Asp.Net. I have a question about a viewstate control. Msdn says that it as a client-side state management but suggest that it can be disabled if there is big data on the page because of performance issues.

So, if this is a client-side state, how does it affect page load time of the site?

最满意答案

对于ViewState是什么和做什么的所有描述，这一切都归结为这是一件事...... ViewState是一堆数据，序列化，base-64编码，并填充到input type="hidden"页面上的元素。

每次将页面呈现给客户端时，ViewState都会发送到客户端。 每次客户端将表单发布到服务器时，ViewState都会发送到服务器。

因此，如果ViewState包含例如200KB的数据，则每次请求都会回送200KB。 200KB的隐藏信息，在页面渲染中看不见 。 可能不重要的数据。 （基本上，残酷。）

所有这些数据是否都需要与每个请求来回发送？ 偶尔可能很方便，但是所有这些状态都需要在每个请求中进行管理吗？ 机会可能不是。 因此，您可以通过不在页面中管理该状态并针对某些页面元素适当地禁用ViewState来调整性能。

某些状态可以完全由服务器端管理，有些可以在其他页面元素中更隐式地管理，有些则根本不需要进行管理。 （由于Web应用程序设计为无状态，如果您可以管理它，那么最后一个选项是理想的。）

For all the descriptions of what ViewState is and does, it all comes down to the fact that it is exactly one thing... ViewState is a bunch of data, serialized, base-64 encoded, and stuffed into an input type="hidden" element on the page.

Every time the page is rendered to the client, ViewState is sent to the client. Every time the client posts the form to the server, ViewState is sent to the server.

So, if ViewState contains, for example, 200KB of data then that's 200KB being sent back and forth with every request. 200KB of hidden information, unseen in the rendering of the page. Potentially unimportant data. (Basically, cruft.)

Does all of that data need to be sent back and forth with every request? It may be convenient once in a while, but does all of that state need to be managed with every request? Chances are, probably not. So you can tune the performance by not managing that state in the page and disabling ViewState appropriately for certain page elements.

Some state can be managed entirely server-side, some can be managed more implicitly in other page elements, some doesn't need to be managed at all. (Since web applications are designed to be stateless, that last option is ideal if you can manage it.)