1.1 ASP.NET性能优化
对于asp.net的性能优化。
1.1.1 工具软件
运行à输入perfmon，可以打开系统自带的性能监视器，可以添加性能计数器。
性能对象
性能计数器
ASP.NET
Application Restarts（应用程序重新启动的次数）
ASP.NET
Requests Queued（排队的请求数）
ASP.NET
Worker Process Restarts（辅助进程重新启动的次数）
ASP.NET 应用程序
Errors Total（错误总数）
ASP.NET 应用程序
Requests/Sec（每秒请求数）
处理器
% CPU Utilization（CPU 使用率）
注意
如果不管客户端负载如何，CPU 使用均低或者无法最大化 CPU 使用，则表明 Web 应用程序中存在锁或资源争用。
另外，下面的性能计数器对确定 Web 应用程序的性能问题也可能有价值。
性能对象
性能计数器
ASP.NET 应用程序
Pipeline Instance Count（管线实例计数）
.NET CLR 异常
# of Exceps Thrown（引发的异常数）
System
Context Switches/sec（每秒上下文切换数）
注：
1. “# of Exceps Thrown”计数器显示应用程序中引发的异常数，因为这些可能有性能方面的暗示。但是，某些代码路径依赖异常才能正常使用。例如，Response 对象上的 Redirect 方法引发 ThreadAbortException 异常，而该异常无法被捕获。因此，使用“Errors Total”计数器跟踪该值（以查看异常在应用程序上是否产生了错误）可能很有用。
2. Context Switches/sec 计数器测量 Web 服务器计算机中的所有 CPU 切换线程上下文的速率。此计数器的高数值通常说明存在较高的锁争用，或者线程在用户模式与内核模式之间有大量切换。如果遇到这种情况，应该使用采样分析器和其他工具进行进一步的研究
1.1.2 优化内容
1.1.2.1 配置优化
1.1.2.1.1 状态管理
a) 当不使用会话状态时禁用它
并不是所有的应用程序或页都需要具体用户的会话状态；您应该在不需要时禁用会话状态。若要禁用页的会话状态，请将 @ Page 指令中的 EnableSessionState 属性设置为 false。
如果页需要访问会话变量，但不会创建或修改它们，则将 @ Page 指令中的 EnableSessionState 属性设置为 ReadOnly。
若要禁用应用程序的会话状态，请在应用程序的 Web.config 文件的 SessionState 节中将 Mode 属性设置为 Off。
b) 针对应用程序需要，选择适当的会话状态提供程序
ASP.NET 为存储应用程序的会话数据提供了多种方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。（您还可以创建自定义会话状态提供程序，以在所选数据存储区中存储会话数据。）每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用进程内提供程序。进程外会话状态选项用于跨多个处理器或多个计算机缩放应用程序，或者用于您希望在服务器或进程重新启动时保留会话数据的情况。
1.1.2.1.2 Web 应用程序
a) 考虑预编译
在对资源（如 ASP.NET 网页）的首次请求中，Web 应用程序是批编译的。如果应用程序中的页都没有编译，批编译功能会成批编译目录中的所有页，以增加磁盘和内存的使用率。可以使用 ASP.NET 编译工具 (Aspnet_compiler.exe) 预编译 Web 应用程序。对于就地编译，该编译工具调用 ASP.NET 运行库来编译站点，其方式与用户向网站请求页时的方式相同。可以预编译 Web 应用程序，以便保留 UI 标记；也可以预编译页，以便不能更改源代码。
b) 去除客户端双连接限制
HTTP 规范表明，一个 HTTP 客户端与任一服务器最多可以同时建立两个 TCP 连接。这可以防止单个浏览器在浏览某个页面（例如，具有120个嵌入的缩略图）时，由于连接请求过多而使服务器负载过重。
<system.net>
<connectionManager>
<add address="*" maxconnection = "40" />
…
（会加快客户端对页面访问速度，但是同时会增加服务器负载，配置需要权衡）
c) 在 Internet 信息服务 5.0 上，在进程外运行 Web 应用程序
默认情况下，IIS 5.0 上的 ASP.NET 将使用进程外辅助进程为请求提供服务。此功能已被优化以提高吞吐量。由于在进程外的辅助进程中运行 ASP.NET 有其功能和优点，建议在生产站点上使用它。
d) IC报价网定期回收进程
为了同时保证稳定性和性能，应该定期回收进程。经过较长的时间，有内存泄漏和 Bug 的资源可以影响 Web 服务器的吞吐量，而回收进程可以清理内存避免这类问题。但是，应当平衡定期回收的需求和过频的回收，因为停止辅助进程、重新加载页面并重新获取资源和数据的开销可能会超过回收的好处。
在使用 IIS 6.0 的 Windows Server 2003 上运行的 ASP.NET Web 应用程序不需要调整进程模型设置，因为 ASP.NET 将使用 IIS 6.0 进程模型设置。
e) 必要时调整应用程序每个辅助进程的线程数.
ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与“ASP.NET Applications”性能对象关联的“Pipeline Instance Count”（管线实例计数）性能计数器，可以在 Windows 性能监视器中监视线程门控。
当 ASP.NET 网页调用外部资源时（例如执行数据库访问或 XML Web services 请求时），页面请求通常停止并释放 CPU 以处理其他线程，直到外部资源响应为止。如果另一个请求正在等待处理，并且线程池中有一个线程释放，则开始处理这个正在等待的请求。这可能导致 ASP.NET 辅助进程或应用程序池中存在大量同时执行的请求和许多正在等待的线程，而它们会影响 Web 服务器的吞吐量，从而对性能产生不利的影响。
为缓解这种情况，可以通过更改IC交易网性能计数器 Machine.config 文件的 processModel 节中的 MaxWorkerThreads 和 MaxIOThreads 属性，手动设置对进程中的线程数的限制。
辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。
分配给进程模型属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。对于有一个或两个处理器的计算机，默认值就可以，但对于有两个以上处理器的计算机的性能，进程中有 100 或 200 个线程则弊大于利。因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上，所以进程中有太多线程往往会降低服务器的速度。线程适当的数目最好通过应用程序的性能测试来确定。
f) 禁用调试模式
在部署生产应用程序或进行任何性能测量之前，始终禁用调试模式。如果启用了调试模式，应用程序的性能可能受到影响。
<system.web>
<compilation debug="false">
…
g) 优化 Web 服务器计算机和特定应用程序的配置文件以符合您的需要
默认情况下，ASP.NET 配置被设置成启用最广泛的功能集并尽量适应最常见的情况。可更改某些默认配置设置以提高应用程序的性能，具体取决于您使用的功能。
1）仅对需要的应用程序启用身份验证
默认情况下，ASP.NET 应用程序的身份验证模式为 Windows 或集成的 NTLM。大多数情况下，最好仅对需要身份验证的应用程序在 Machine.config 文件中禁用身份验证，并在 Web.config 文件中启用身份验证。
2）根据适当的请求和响应编码设置来配置应用程序
ASP.NET 默认编码格式为 UTF-8。如果您的应用程序仅使用 ASCII 字符，请配置您的 ASCII 应用程序以获得稍许的性能提高。
3）考虑对应用程序禁用 AutoEventWireup
在 Machine.config 文件中将 AutoEventWireup 属性设置为 false，意味着页面不会将页事件绑定到基于名称匹配的方法（例如 Page_Load）。如果禁用 AutoEventWireup，页面将通过将事件连接留给您而不是自动执行它，获得稍许的性能提升。
如果想要处理页事件，可以使用两种策略之一。第一种策略是重写基类中的方法。例如，可以为页加载事件重写 Page 对象的 OnLoad 方法，而不是使用 Page_Load 方法。（务必调用基方法以确保引发所有事件。）第二种策略是使用 Visual Basic 中的 Handles 关键字或 C# 中的委托连接来绑定到事件。
4）从请求处理管线中移除不用的模块
默认情况下，服务器计算机的 Machine.config 文件中 HttpModules 节点的所有功能均保留为活动状态。根据应用程序所使用的功能，您可以从请求管线中移除不用的模块以获得稍许的性能提升。检查每个模块及其功能，并按您的需要自定义它。例如，如果您在应用程序中不使用会话状态和输出缓存，则可以从 HttpModules 列表中移除它们，以便请求在不执行其他有意义的处理时，不必调用这些模块。
1.1.2.2 代码优化
1.1.2.2.1 页面和服务器控件处理
a) 避免到服务器的不必要的往返行程
在某些情况下不必使用 ASP.NET 服务器控件和执行回发事件处理。例如，在 ASP.NET 网页中验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以进行验证或将其写入数据存储区，请避免使用导致到服务器的往返行程的代码，这样可以提高页的性能并改善用户体验。您也可以不执行整个往返行程，而是使用客户端回调从服务器中读取数据。
页面类实现ICallbackEventHandler接口，注册GetCallbackEventReference方法，也就是ajax的回调实现。
针对一次需要载入很多控件的页面(载入比较耗时的页面)，我们可以使用ajax技术来达到一定的页面访问性能提升。
b) 使用 Page 对象的 IsPostBack 属性来避免对往返行程执行不必要的处理
如果您编写处理服务器控件回发处理的代码，有时可能需要代码仅在首次请求页时执行，而不是每次回发时都执行。根据该页是否是响应服务器控件事件生成的，使用 IsPostBack 属性有条件地执行代码。
将仅需要首次请求页面时执行的代码放在IsPostBack条件中运行。
c) 只在必要时保存服务器控件视图状态
自动视图状态管理使服务器控件可以在往返行程中重新填充它们的属性值，而您不需要编写任何代码。但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能影响性能。了解在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能，这样是有帮助的。例如，如果您将服务器控件绑定到每个往返行程上的数据，因为控件的值会在数据绑定期间用新值替换，所以保存的视图状态没有用处。在这种情况下，禁用视图状态可以节省处理时间并减少页的大小。
默认情况下，为所有服务器控件启用视图状态。若要禁用它，请将控件的 EnableViewState 属性设置为 false。
还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用。
@ Control 指令中还支持 EnableViewState 属性以指定是否为用户控件启用视图状态。
查看视图状态的方法：
若要分析服务器控件在页中使用的视图状态的大小，请通过将 trace="true" 属性包含在 @ Page 指令中启用对该页的跟踪。然后在跟踪输出中，查看“控件层次结构”表的“Viewstate”列。
下面情况基本上可以禁用viewstate：
（1）页面控件 （.ascx）
（2）页面不回传给自身。
（3）无需对控件的事件处理。
（4）控件没有动态的或数据绑定的属性值（或对于每个postpack都在代码中处理）
d) 除非有特殊的原因要关闭缓冲，否则使其保持打开状态
禁用 ASP.NET 网页的缓冲会导致大量的性能开销。
e) Server.Transfer和Response.Redirect的选择
Response.Redirect 简单地告诉浏览器访问另一个页面。Server.Transfer 有利于减少服务器请求，保持地址栏 URL 不变，允许你将 query string 和 form 变量传递到另一个页面，可以隐藏url中传递的参数。
Response.Redirect可以跨站点跳转，Server.Transfer只能同站点跳转。
微软建议：
使用 Transfer Server 对象或跨页发送的方法在同一个应用程序中的不同 ASP.NET 页之间重定向
如无特殊要求，应优先选择Server.Transfer进行页面跳转
1.1.2.2.2 数据访问
a) 将 SQL Server 和存储过程用于数据访问
在 .NET Framework 提供的所有数据访问方法中，使用 SQL Server 进行数据访问是生成高性能、可缩放 Web 应用程序的推荐选择。使用托管 SQL Server 提供程序时，可通过尽可能使用编译的存储过程而不是 SQL 命令获得额外的性能提高。
（仅针对数据库选择SQL Server，数据库为其他的可以忽略此选项）
b) 将 SqlDataReader 类用于快速只进数据游标
SqlDataReader 类提供了从 SQL Server 数据库检索的只进数据流。如果您可以在 ASP.NET 应用程序中使用只读流，则 SqlDataReader 类提供比 DataSet 类更高的性能。SqlDataReader 类使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。例如，当绑定到 SqlDataSource 控件时，通过将 DataSourceMode 属性设置为 DataReader，您将获得更好的性能。（使用数据读取器会导致某些功能的丢失。）另外，SqlDataReader 类实现 IEnumerable 接口，该接口也使您可以将数据绑定到服务器控件。
(仅针对数据库选择SQL Server，数据库为其他的可以忽略此选项) MySql中对应MySqlDataReader，根据需要选择。
c) 尽可能缓存数据和页输出
ASP.NET 提供了一些机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求（特别是在站点中预期将有较大通讯量的区域），可以优化这些页的性能。与使用 .NET Framework 的任何其他功能相比，适当地使用缓存可以更好地提高站点的性能。
在使用 ASP.NET 缓存时，应注意以下事项。首先，不要缓存太多项。缓存每个项都有内存开销。不要缓存容易重新计算和很少使用的项。其次，给缓存项分配的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且会导致额外的代码清除和垃圾回收工作。使用与“ASP.NET Applications”性能对象关联的“Cache Total Turnover Rate”（缓存总流通率）性能计数器，您可以监视缓存中由于项到期而导致的周转。高周转率可能说明存在问题，特别是当项在到期前被移除时。（这种情况有时称作内存压力。）
可以考虑把静态的、变化不大的或者不经常变化需要动态加载的内容放入控件中，使用缓存技术。
<%@ OutputCache Duration="100" VaryByParam="none" %>
d) 适当地使用 SQL 缓存依赖项
ASP.NET 同时支持基于表的轮询和查询通知，具体取决于所使用的 SQL Server 的版本。所有 SQL Server 版本都支持基于表的轮询。在基于表的轮询中，如果表中的任何内容发生更改，所有侦听器都会失效。这可能导致应用程序中不必要的改动。建议不要将基于表的轮询用于具有许多频繁更改的表。例如，建议将基于表的轮询用于很少更改的目录表。建议不要将基于表的轮询用于订单表，订单表具有更频繁的更新。SQL Server 2005 支持查询通知。查询通知支持特定查询，从而减少在表更改时发送的通知数量。虽然它比基于表的轮询提供更好的性能，但是它无法扩展到适应数千个查询。
(仅针对数据库选择SQL Server，数据库为其他的可以忽略此选项)
e) 使用数据源分页和排序而不是 UI（用户界面）分页和排序
DetailsView 和 GridView 等数据控件的 UI 分页功能可用于支持 ICollection 接口的任何数据源对象。对于每个分页操作，数据控件查询数据源的整个数据集并选择要显示的行，并放弃其余的数据。如果数据源实现 DataSourceView 并且 CanPage 属性返回 true，则数据控件将使用数据源分页而不是 UI 分页。在这种情况下，数据控件仅查询每个分页操作需要的行。因此，数据源分页比 UI 分页更高效。只有 ObjectDataSource 数据源控件才支持数据源分页。若要在其他数据源控件上启用数据源分页，必须从该数据源控件继承并修改其行为。
f) 平衡事件验证的安全性受益和性能开销
从 System.Web.UI.WebControls 和 System.Web.UI.HtmlControls 类派生的控件可以验证事件是否源自该控件所呈现的用户界面。这样有助于防止控件响应伪造的事件通知。例如，DetailsView 控件可以防止 Delete（删除）调用（控件中本质上不支持该调用）的处理以及被操纵而删除数据。此验证会带来一定的性能开销。可以使用 EnableEventValidation 配置元素和 RegisterForEventValidation 方法控制此行为。验证的开销取决于页上的控件数量，并在几个百分点范围内。
强烈建议不要禁用事件验证。在禁用事件验证之前，应该确保不会构造任何可能对应用程序具有意外影响的回发。
g) 除非必要，否则避免使用视图状态加密
视图状态加密会阻止用户能够读取隐藏视图状态字段中的值。典型情况是在 DataKeyNames 属性中带有一个标识符字段的 GridView 控件。标识符字段是协调对记录的更新所必需的。由于不想要标识符对用户可见，因此可以加密视图状态。但是，加密对于初始化具有恒定的性能开销，并具有取决于被加密的视图状态大小的附加开销。加密为每次页加载而设置，因此在每次页加载时都会发生相同的性能影响。
h) 使用 SqlDataSource 缓存、排序和筛选
如果 SqlDataSource 控件的 DataSourceMode 属性设置为 DataSet，则 SqlDataSource 能够缓存查询产生的结果集。如果以这种方式缓存数据，则控件的筛选和排序操作（使用 FilterExpression 和 SortParameterName 属性进行配置）将使用缓存的数据。在许多情况下，如果缓存整个数据集，并使用 FilterExpression 和 SortParameterName 属性进行排序和筛选，而不是使用带“WHERE”和“SORT BY”子句的 SQL 查询（对于这些查询，每个选择操作都要访问数据库），应用程序会运行得更快。
(根据具体控件，仅支持部分数据库)
1.1.2.2.3 编码实践
a) 不要依赖代码中的异常
异常会大大地降低性能，所以您应该避免将它们用作控制正常程序流的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作，而不要捕捉异常本身和处理该状态。常见的代码检测方案包括：检查 null，将一个值分配给将分析为数值的 String，或在应用数学运算前检查特定值。
b) 在托管代码中重写调用密集型的 COM 组件
.NET Framework 提供了一个简单的方法与传统的 COM 组件进行交互。其优点是可以在保留现有 COM 组件投资的同时利用 .NET 的功能。但是在某些情况下，保留旧组件的性能开销使得将组件迁移到托管代码是值得的。每一情况都是不一样的，决定是否需要迁移组件的最好方法是对网站运行性能测量。建议研究一下如何将经常调用的任何 COM 组件迁移到托管代码。
许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。在这种情况下，最大的性能障碍之一是将数据从非托管环境封送到托管环境。因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行单个调用而不是一系列小调用。例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。
一旦处理完任何 COM 对象或本机资源就释放它们。这样，其他请求就能够使用它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。
c) 避免单线程单元 (STA) COM 组件
默认情况下，ASP.NET 不允许 STA COM 组件在页内运行。若要运行它们，必须在 .aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中。这样就将页执行用的线程池切换到 STA 线程池，而且使 HttpContext 和其他内置对象可用于 COM 对象。避免使用 STA COM 组件是一种性能优化，因为它避免了将多线程单元 (MTA) 封送到 STA 线程的任何调用。
如果必须使用 STA COM 组件，则应避免在执行期间进行大量调用，并尝试在每次调用期间发送尽可能多的信息。首选机制是推迟对象的创建，推荐的做法是仅在需要时或者在 Page_Load 方法中构造 COM 组件和外部资源。
永远不要将 STA COM 组件存储在可以由构造它们的线程以外的其他线程访问的共享资源（如缓存或会话状态）里。即使 STA 线程调用 STA COM 组件，也只有构造此 STA COM 组件的线程能够为该调用服务，而这要求封送处理对创建者线程的调用。此封送处理可能产生重大的性能损失和可伸缩性问题。在这种情况下，请考虑使 COM 组件成为 MTA COM 组件或在托管代码中重写该组件。
1.1.3 附录—计数器选择参考
ASP.NET 系统性能计数器
Application Restarts（应用程序重新启动的次数）
Web 服务器的生存期中应用程序重新启动的次数。每次引发一个 Application_OnEnd 事件时，应用程序重新启动次数都会增加 1 次。重新启动应用程序的原因可能是：对 Web.config 文件做出了更改、对存储在应用程序的 Bin 目录中的程序集做出了更改，或者由于 ASP.NET 网页中发生了大量更改而必须重新编译应用程序。此计数器的意外增长可能意味着问题正导致您的 Web 应用程序循环。在这种情况下，应尽快进行调查。
每次重新启动 Internet 信息服务 (IIS) 主机时，该值都会重置为零.
Application Running（运行的应用程序数）
同时运行于服务器计算机上的应用程序的数目。
Requests Disconnected（断开的请求数）
已经由于通信错误而断开的请求数。
Requests Queued（排队的请求数）
队列中等待服务的请求的数目。当该数开始随客户端负载的增多而线性增加时，Web 服务器计算机已达到能同时处理的请求数的上限。该数的默认最大值为 5,000。可以在 Machine.config 文件中更改此设置。
Requests Rejected（拒绝的请求数）
由于服务器资源不足无法处理请求而未能执行的请求的总数。该计数器表示返回 503 HTTP 状态代码（指示服务器太忙）的请求的数目。
Request Wait Time（请求等待时间）
队列中最近一次请求等待处理的毫秒数。
Session State Server Connections Total（会话状态服务器连接总数）
存储进程外会话状态数据的计算机的会话状态连接总数。
Session SQL Server Connections Total（会话 SQL Server 连接总数）
存储会话状态数据的 Microsoft SQL Server 数据库的会话状态连接总数。
State Server Sessions Abandoned（放弃的状态服务器会话数）
已显式放弃的用户会话的数目。这些会话是由特定的用户操作中止的，例如关闭浏览器或导航到另一个站点。该计数器仅在正运行状态服务器服务 (aspnet_state) 的计算机上提供。
State Server Sessions Active（活动的状态服务器会话数）
当前处于活动状态的用户会话的数目。该计数器仅在正运行状态服务器服务 (aspnet_state) 的计算机上提供。
State Server Sessions Timed Out（超时的状态服务器会话数）
由于用户不操作而进入不活动状态的用户会话的数目。该计数器仅在正运行状态服务器服务 (aspnet_state) 的计算机上提供。
State Server Sessions Total（状态服务器会话总数）
进程的生存期中创建的会话数。该计数器是以下会话数的总数：“活动的状态服务器会话数”、“放弃的状态服务器会话数”和“超时的状态服务器会话数”。该计数器仅在正运行状态服务器服务 (aspnet_state) 的计算机上提供。
Worker Process Restarts（辅助进程重新启动的次数）
服务器计算机上辅助进程重新启动的次数。如果辅助进程意外地失败或者被有意地回收，则能够被重新启动。如果该计数器的值意外增加，应尽快进行调查。
Worker Process Running（运行的辅助进程数）
服务器计算机上运行的辅助进程的数目。
ASP.NET Application 性能计数器
ASP.NET 支持下表中所列的应用程序性能计数器。利用这些计数器可以监视 ASP.NET 应用程序的单个实例的性能。这些计数器可以使用一个名为“__Total__”的唯一实例。该实例聚合 Web 服务器上所有应用程序的计数器（类似于本主题前面描述的全局计数器）。__Total__ 实例始终可用。当服务器上当前没有任何应用程序执行时，该计数器将显示零。
Anonymous Requests（匿名请求数）
使用匿名身份验证的请求数。
Anonymous Requests/Sec（每秒匿名请求数）
每秒使用匿名身份验证的请求的数目。
Cache Total Entries（缓存总项数）
缓存中的总项数。该计数器既包括通过 ASP.NET 页框架使用缓存的情况，也包括通过缓存 API 使用应用程序缓存的情况。
Cache Total Hits（缓存命中总数）
缓存中命中的总数。该计数器既包括通过 ASP.NET 页框架使用缓存的情况，也包括通过缓存 API 使用应用程序缓存的情况。
Cache Total Misses（缓存未命中总数）
每个应用程序未能命中的缓存请求数。该计数器既包括通过 ASP.NET 页框架使用缓存的情况，也包括通过缓存 API 使用应用程序缓存的情况。
Cache Total Hit Ratio（缓存总命中率）
缓存命中数和未命中数的比率。该计数器既包括通过 ASP.NET 页框架 NET 使用缓存的情况，也包括通过缓存 API 使用应用程序缓存的情况。
Cache Total Turnover Rate（缓存总流通率）
每秒对缓存的添加数和移除数，它有助于确定缓存的使用效率。如果流通率较高，则表示未能有效地使用缓存。
Cache API Entries（缓存 API 项数）
应用程序缓存中项的总数。
Cache API Hits（缓存 API 命中数）
当只通过外部缓存 API 访问时，缓存中命中的总数。该计数器不跟踪通过 ASP.NET 页框架使用缓存的情况。
Cache API Misses（缓存 API 未命中数）
当通过外部缓存 API 访问时，缓存未能命中的请求总数。该计数器不跟踪通过 ASP.NET 页框架使用缓存的情况。
Cache API Hit Ratio（缓存 API 命中率）
当通过外部缓存 API 访问时，缓存命中数与未命中数的比率。该计数器不跟踪通过 ASP.NET 页框架使用缓存的情况。
Cache API Turnover Rate（缓存 API 流通率）
当通过外部 API 使用时（不包括 ASP.NET 页框架的使用），每秒对缓存的添加数和移除数。它有助于确定缓存的使用效率。如果流通率较高，则表示未能有效使用地缓存。
Compilations Total（编译总数）
当前 Web 服务器进程的生存期中发生的编译的总数。在服务器上动态编译具有 .aspx、.asmx、.ascx 或 .ashx 扩展名的文件（即代码隐藏源文件）时会发生编译。
当对应用程序的所有部分发出请求时，该数字将在开始时达到峰值。但是，一旦发生编译，便会将生成的已编译输出保存到磁盘中，直到其源文件更改之前，一直重复使用该输出。这意味着，即使是在进程重新启动时，计数器也可能保持为零（不活动），直到应用程序被修改或重新部署。
Debugging Requests（调试请求数）
调试启用时发生的请求的数目。
Errors During Preprocessing（预处理过程中发生的错误数）
分析期间发生的错误数（不包括编译错误和运行时错误）。
Errors During Compilation（编译过程中发生的错误数）
动态编译期间发生的错误数（不包括分析器错误和运行时错误）。
Errors During Execution（执行过程中发生的错误数）
执行 HTTP 请求期间发生的错误总数（不包括分析器错误和编译错误）。
Errors Unhandled During Execution（执行过程中未处理的错误数）
执行 HTTP 请求过程中发生的未处理错误的总数。未处理的错误是用户代码中任何未捕获的运行时异常，该异常进入 ASP.NET 的内部错误处理逻辑。此规则在以下情况下会出现例外：
启用了自定义错误、定义了错误页，或两种情况同时发生。
用户代码中定义了 Page_Error 事件，清除了错误（使用 ClearError 方法）或执行了重定向。
Errors Unhandled During Execution/Sec（执行过程中每秒未处理的错误数）
执行 HTTP 请求过程中每秒未处理的异常的数目。
Errors Total（错误总数）
执行 HTTP 请求期间发生的错误总数（包括任何分析器错误、编译错误或运行时错误）。此计数器为 Errors During Compilation、Errors During Preprocessing 和 Errors During Execution 计数器的总和。正常运行的 Web 服务器不应发生错误。如果 ASP.NET Web 应用程序中发生错误，它们可能会歪曲任何吞吐量结果，因为错误恢复的代码路径与原来的完全不一样。在性能测试前应调查并修复应用程序中的所有 Bug。
Errors Total/Sec（每秒错误总数）
执行 HTTP 请求期间每秒发生的错误数（包括任何分析器错误、编译错误或运行时错误）。
Output Cache Entries（输出缓存项数）
输出缓存中项的总数。
Output Cache Hits（输出缓存命中数）
从输出缓存中得到服务的请求的总数。
Output Cache Misses（输出缓存未命中数）
每个应用程序未能命中的输出缓存请求的数目。
Output Cache Hit Ratio（输出缓存命中率）
从输出缓存中得到服务的请求总数所占的百分比。
Output Cache Turnover Rate（输出缓存周转率）
每秒对输出缓存的添加数和移除数。如果流通率较高，则表示未能有效地使用缓存。
Pipeline Instance Count（管线实例计数）
指定的 ASP.NET 应用程序的活动请求管线实例的数目。由于只有一个执行线程可以在管线实例中运行，这个数给出了给定应用程序能同时处理的最大请求数。大多数情况下，负载大时（这表明 CPU 被大量使用），该值较低比较好。
Request Bytes In Total（传入请求字节总数）
所有请求的总大小（以字节为单位）。
Request Bytes Out Total（传出请求字节总数）
发送到客户端的响应的总大小（以字节为单位）。这不包括 HTTP 响应标头。
Requests Executing（执行的请求数）
当前正在执行的请求的数目。
Requests Failed（失败的请求数）
失败请求的总数。所有大于或等于 400 的状态代码都会增加该计数器的值。
导致状态代码 401 的请求将增加该计数器和“Requests Not Authorized”计数器的值。导致状态代码 404 或 414 的请求将增加该计数器和“Requests Not Found”计数器的值。导致状态代码 500 的请求将增加该计数器和“Requests Timed Out”计数器的值。
Requests Not Found（未找到的请求数）
由于未找到资源而失败（状态代码 404 或 414）的请求数。
Requests Not Authorized（未经授权的请求数）
由于没有授权而失败的（状态代码 401）请求数。
Requests Succeeded（成功的请求数）
成功执行的（状态代码 200）请求数。
Requests Timed Out（超时的请求数）
超时的请求数（状态代码 500）。
Requests Total（请求总数）
启动服务后请求的总数。
Requests/Sec（每秒请求数）
每秒执行的请求数。这代表应用程序的当前吞吐量。负载不变的情况下，该值应保持在某一范围内，禁止其他服务器工作（如垃圾回收、缓存清理线程、外部服务器工具等）。
Sessions Active（活动的会话数）
当前活动的会话数。该计数器仅在内存中会话状态下受支持。
Sessions Abandoned（放弃的会话数）
已显式放弃的会话数。该计数器仅在内存中会话状态下受支持。
Sessions Timed Out（超时的会话数）
超时的会话数。该计数器仅在内存中会话状态下受支持。
Sessions Total（会话总数）
会话总数。该计数器仅在内存中会话状态下受支持。
Transactions Aborted（中止的事务数）
所有活动 ASP.NET 应用程序的已取消的事务数。
Transactions Committed（提交的事务数）
所有活动 ASP.NET 应用程序的已提交的事务数。
Transactions Pending（挂起的事务数）
所有活动 ASP.NET 应用程序的正在进行的事务数。
Transactions Total（事务总数）
所有活动 ASP.NET 应用程序的事务总数。
Transactions/Sec（每秒事务数）
所有活动 ASP.NET 应用程序的每秒启动的事务数。
"
