返回页首
视图状态：无声的性能杀手
从某种意义上说，视图状态是有史以来最伟大的事情。毕竟，视图状态使得页面和控件能够在回发之间保持状态。因此，您不必像在传统的 ASP 中那样编写代码，以防止在单击按钮时文本框中的文本消失，或在回发后重新查询数据库和重新绑定 DataGrid。
但是视图状态也有缺点：当它增长得过大时，它便成为一个无声的性能杀手。某些控件（例如文本框）会根据视图状态作出相应判断。其他控件（特别是 DataGrid 和 GridView）则根据显示的信息量确定视图状态。如果 GridView 显示 200 或 300 行数据，我会望而生畏。即使 ASP.NET 2.0 视图状态大致是 ASP.NET 1 x 视图状态的一半大小，一个糟糕的 GridView 也可以容易地将浏览器和 Web 服务器之间的连接的有效带宽减少 50％ 或更多。
您可以通过将 EnableViewState 设置为 false 来关闭单个控件的视图状态，但某些控件（特别是 DataGrid）在不能使用视图状态时会失去某些功能。控制视图状态的更佳解决方案是将其保留在服务器上。在 ASP.NET 1.x 中，您可以重写页面的 LoadPageStateFromPersistenceMedium 和 SavePageStateToPersistenceMedium 方法并按您喜欢的方式处理视图状态。图 4 中的代码显示的重写可防止视图状态保留在隐藏字段中，而将其保留在会话状态中。当与默认会话状态进程模型一起使用时（即，会话状态存储在内存中的 ASP.NET 辅助进程中时），在会话状态中存储视图状态尤其有效。相反，如果会话状态存储在数据库中，则只有测试才能显示在会话状态中保留视图状态会提高还是降低性能。
在 ASP.NET 2.0 中使用相同的方法，但是 ASP.NET 2.0 能够提供更简单的方法将视图状态保留在会话状态中。首先，定义一个自定义页适配器，其 GetStatePersister 方法返回 .NET Framework SessionPageStatePersister 类的一个实例：
public class SessionPageStateAdapter :System.Web.UI.Adapters.PageAdapter{public override PageStatePersister GetStatePersister () {return new SessionPageStatePersister(this.Page); }}
然后，通过将 App.browsers 文件按以下方式放入应用程序的 App_Browsers 文件夹，将自定义页适配器注册为默认页适配器：
<browsers><browser refID="Default"><controlAdapters><adapter controlType="System.Web.UI.Page"adapterType="SessionPageStateAdapter" /></controlAdapters></browser></browsers>
（您可以将文件命名为您喜欢的任何名称，只要它的扩展名为 .browsers 即可。）此后，ASP.NET 将加载页适配器并使用返回的 SessionPageStatePersister 以保留所有页面状态，包括视图状态。
使用自定义页适配器的一个缺点是它全局性地作用于应用程序中的每一页。如果您更愿意将其中一些页面的视图状态保留在会话状态中而不保留其他页面的视图状态，请使用图 4 中显示的方法。另外，如果用户在同一会话中创建多个浏览器窗口，您使用该方法可能会遇到问题。
返回页首
SQL Server 会话状态：另一个性能杀手
ASP.NET 使得在数据库中存储会话状态变得简单：只需切换 web.config 中的开关，会话状态就会轻松地移动到后端数据库。对于在 Web 领域中运行的应用程序来说，这是一项重要功能，因为它允许该领域中的每个服务器共享会话状态的一个公共库。添加的数据库活动降低了单个请求的性能，但是可伸缩性的提高弥补了性能的损失。
这看起来都还不错，但是您略微考虑一下下列几点，情况就会有所不同：
• 即使在使用会话状态的应用程序中，大多数页也不使用会话状态。
• 默认情况下，ASP.NET 会话状态管理器对每个请求中的会话数据存储执行两个访问（一个读取访问和一个写入访问），而不管请求的页是否使用会话状态。
换句话说，当您使用 SQL Server™ 会话状态选项时，您在每个请求中都要付出代价（两个数据库访问）— 甚至在与会话状态无关的页面的请求中。这会直接对整个网站的吞吐量造成负面影响。
图 5 消除不必要的会话状态数据库访问
那么您应该怎么办呢？很简单：禁用不使用会话状态的页中的会话状态。这样做总是一个好办法，但是当会话状态存储在数据库中时，该方法尤其重要。图 5 显示如何禁用会话状态。如果页面根本不使用会话状态，请在其 Page 指令中包含 EnableSessionState="false"，如下所示：
<%@ Page EnableSessionState="false" ... %>
该指令阻止会话状态管理器在每个请求中读取和写入会话状态数据库。如果页面从会话状态中读取数据，但却不写入数据（即，不修改用户会话的内容），则将 EnableSessionState 设置为 ReadOnly，如下所示：
<%@ Page EnableSessionState="ReadOnly" ... %>
最后，如果页面需要对会话状态进行读/写访问，则省略 EnableSessionState 属性或将其设置为 true：
<%@ Page EnableSessionState="true" ... %>
通过以这种方式控制会话状态，可以确保 ASP.NET 只在真正需要时才访问会话状态数据库。消除不必要的数据库访问是构建高性能应用程序的第一步。
顺便说一下，EnableSessionState 属性是公开的。该属性自 ASP.NET 1.0 以来就已经进行了说明,但是我至今仍很少见到开发人员利用该属性。也许是因为它对于内存中的默认会话状态模型并不十分重要。但是它对于 SQL Server 模型却很重要。
返回页首
未缓存的角色
以下语句经常出现于 ASP.NET 2.0 应用程序的 web.config 文件以及介绍 ASP.NET 2.0 角色管理器的示例中：
<roleManager enabled="true" />
但正如以上所示，该语句确实会对性能产生明显的负面影响。您知道为什么吗？
默认情况下，ASP.NET 2.0 角色管理器不会缓存角色数据。相反，它会在每次需要确定用户属于哪个角色（如果有）时参考角色数据存储。这意味着一旦用户经过了身份验证，任何利用角色数据的页（例如，使用启用了安全裁减设置的网站图的页，以及使用 web.config 中基于角色的 URL 指令进行访问受到限制的页）将导致角色管理器查询角色数据存储。如果角色存储在数据库中，那么对于每个请求需要访问多个数据库的情况，您可以轻松地免除访问多个数据库。解决方案是配置角色管理器以在 Cookie 中缓存角色数据：
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
