ASP.NET性能计数器<转>

简介:
ASP.NET 支持两组性能计数器:系统和应用程序。前者在 ASP.NET 性能计数器对象中的 PerfMon 中公开;后者在 ASP.NET Applications 性能对象中公开。ASP.NET 性能对象中的 State Server Sessions 计数器(仅适用于在其中运行状态服务器的服务器计算机)和 ASP.NET Applications 性能对象中的 Sessions 计数器(仅适用于进程中发生的用户会话)之间存在很大的差异。

   注意 每 400 毫秒更新一次与每个性能计数器关联的值。

    在监视 ASP.NET Web 应用程序的性能时,应该始终跟踪下表中列出的性能计数器。
性能对象 性能计数器
ASP.NET Application Restarts
ASP.NET Requests Queued
ASP.NET Worker Process Restarts
ASP.NET Applications Errors Total
ASP.NET Applications Requests/Sec
Processor % CPU Utilization



    % CPU Utilization 计数器监视 Web 服务器计算机上的 CPU 使用情况。无论客户端负载如何,CPU 使用率很低或者无法达到 CPU 最大使用率就意味着 Web 应用程序中存在资源或锁定竞争。

    此外,在确定 Web 应用程序性能问题时,下表中列出的性能计数器是非常有用的。

性能对象 性能计数器
ASP.NET Applications Pipeline Instance Count
.NET CLR Exceptions # of Exceps Thrown
System Context Switches/sec


    # of Exceps Thrown 计数器显示应用程序中引发的异常数量,因为它们可能会对性能造成不利影响。但是,某些代码路径必须依赖异常才能正常工作。例如,HttpResponse.Redirect 方法始终引发一个无法捕获的异常 ThreadAbortException。因此,使用 Errors Total 计数器跟踪引发的异常数量以查看异常是否在应用程序上生成错误更有用处。

    Context Switches/sec 计数器测量 Web 服务器计算机中所有 CPU 切换线程上下文的速率。如果此计数器的数值较大,则表明锁定竞争很激烈,或者线程在用户和内核模式之间频繁切换。可能还需要使用采样分析器和其他工具进行进一步的分析。

    以下列表详细介绍了 ASP.NET 和 ASP.NET Applications 性能对象中的计数器。

    ASP.NET 系统性能计数器

    ASP.NET 支持以下 ASP.NET 系统性能计数器。它们汇集 Web 服务器计算机上所有 ASP.NET 应用程序的信息,或者它们通常应用于运行相同应用程序的 ASP.NET 服务器的系统。它们可能包含 Web 场和 Web 园。

    Application Restarts :在 Web 服务器的生存期内应用程序已重新启动的次数。每发生一次 Application_OnEnd 事件,应用程序重新启动次数就会增加一次。可能由于以下原因而出现应用程序重新启动:更改 Web.config 文件,更改应用程序 \Bin 目录中存储的程序集,或者对 Web 表单页更改过多。此计数器意外增加可能意味着,未知问题将导致 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 :存储会话状态数据的 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 :在进程生存期内创建的会话数。此计数器是 State Server Sessions Active、State Server Sessions Abandoned 和 State Server Sessions Timed Out 的累积值。该计数器只用于运行状态服务器服务 (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 在内部使用的缓存,又包括通过公开的 API 在外部使用的缓存。
    Cache Total Turnover Rate :每秒对总缓存的添加数和移除数。这对确定缓存的使用效率很有帮助。如果反复很大,则无法有效地使用缓存。
    Cache API Entries :应用程序缓存中的总项数。
    Cache API Hits :当只通过外部缓存 API 访问缓存时,缓存中的命中总数。该计数器不跟踪由 ASP.NET 在内部使用的缓存。
    Cache API Misses:在通过外部缓存 API 访问时,失败的缓存请求的总数。该计数器不跟踪由 ASP.NET 在内部使用的缓存。
    Cache API Hit Ratio :在通过外部缓存 API 访问时,缓存命中与未命中的比率。该计数器不跟踪由 ASP.NET 在内部使用的缓存。
    Cache API Turnover Rate :在通过外部 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 内部错误处理逻辑。在以下情况下,此规则出现例外情况:
    1:启用了自定义错误和/或定义了错误页面。
    2:在用户代码中定义了 Page_Error 事件并且清除了该错误(使用 HttpServerUtility.ClearError 方法)或执行重定向。

    Errors Unhandled During Execution/Sec :在执行 HTTP 请求期间每秒发生的未处理异常的数量。
    Errors Total :在执行 HTTP 请求期间发生的错误的总数。包括任何分析程序、编译或运行时错误。此计数器是 Errors During Compilation、 Errors During Preprocessing 和 Errors During Execution 计数器的总和。正常工作的 Web 服务器不应生成错误。如果在 ASP.NET Web 应用程序中发生错误,则它们可能会由于错误恢复的代码路径不同而歪曲吞吐量结果。在执行调试之前,调查并修复应用程序中的任何错误。
    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 计数器。

    注意 在拒绝请求(无法完成,因为拒绝是由 IIS 而不是由进程模型完成的)时,等价的 ASP 计数器也将增加。

    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 :中止的事务数。
    Transactions Committed:提交的事务数。
    Transactions Pending :进行中的事务数。
    Transactions Total :服务启动后的事务总数。
    Transactions/Sec :每秒启动的事务数。

原文地址:http://hi.baidu.com/4712635/blog/item/8bb3d7950426024dd1135e88

 

 

本文转自温景良(Jason)博客园博客,原文链接:http://www.cnblogs.com/wenjl520/archive/2009/12/15/1624887.html,如需转载请自行联系原作者

相关文章
|
21天前
|
人工智能 物联网 开发者
**.NET技术革新赋能软件开发:从.NET 5的性能飞跃、跨平台支持,到微服务、物联网、AI和游戏开发的广泛应用。
【7月更文挑战第4天】**.NET技术革新赋能软件开发:从.NET 5的性能飞跃、跨平台支持,到微服务、物联网、AI和游戏开发的广泛应用。随着云集成深化、开源社区壮大,未来将聚焦性能优化、云原生应用及新兴技术融合,培养更多开发者,驱动软件创新。**
84 1
|
1月前
|
SQL 设计模式 开发框架
.NET异步有多少种实现方式?(异步编程提高系统性能、改善用户体验)
想要知道.NET异步有多少种实现方式,首先我们要知道.NET提供的执行异步操作的三种模式,然后再去了解.NET异步实现的四种方式。
|
2月前
|
缓存 监控 算法
【专栏】.NET 开发:实现卓越性能的途径
【4月更文挑战第29天】本文探讨了.NET开发中的性能优化,强调了理解性能问题根源和使用分析工具的重要性。基础优化包括代码优化(如减少计算、避免内存泄漏)、资源管理及选择合适算法。高级策略涉及并行编程、缓存策略、预编译(AOT)和微服务架构。持续性能测试与监控是关键,包括性能测试、监控分析和建立优化反馈循环。开发者应持续学习和实践性能优化,以构建高性能应用。
|
7月前
|
人工智能 编解码 Cloud Native
微软发布 .NET 8 开源开发平台:引入 PGO、AVX-512 支持,性能提升 20%
对企业来说特别重要的是,.NET 8 是一个长期支持 (LTS) 版本,这意味着它将获得三年的支持和补丁,而标准期限支持 (STS) 版本则是 18 个月。对于开发人员来说,特别重要的是 .NET 团队正在向期待已久的原生提前编译(NativeAOT)迈进 。
128 2
|
Rust 数据可视化 安全
【番外篇】Rust环境搭建+基础开发入门+Rust与.NET6、C++的基础运算性能比较
突然想打算把Rust作为将来自己主要的副编程语言。当然,主语言还是C#,毕竟.NET平台这么强大,写起来就是爽。缘起:之前打算一些新的产品或者新的要开发的东西,由于没有历史包袱,就想重新选型一下,在.NET平台(C#语言)、Golang、Rust里面进行选择一个。
272 0
【番外篇】Rust环境搭建+基础开发入门+Rust与.NET6、C++的基础运算性能比较
|
SQL Oracle 网络协议
【.NET 6】使用EF Core 访问Oracle+Mysql+PostgreSQL并进行简单增改操作与性能比较
唠嗑一下。都在说去O或者开源,但是对于数据库选型来说,很多人却存在着误区。例如,去O,狭义上讲,是去Oracle数据库。但是从广义上来说,是去Oracle公司产品或者具有漂亮国垄断地位和需要商业授权的数据库产品。
370 0
【.NET 6】使用EF Core 访问Oracle+Mysql+PostgreSQL并进行简单增改操作与性能比较
|
Java 开发工具
『性能调优』在生产环境中,.Net如何定位系统内存泄露具体位置
📣读完这篇文章里你能收获到 - 生产环境排查内存问题的工具 - 排查命令的使用 - 排查经验分享
365 1
『性能调优』在生产环境中,.Net如何定位系统内存泄露具体位置
|
数据库 C++ Windows
『性能调优』在开发环境中,.NET如何排查CPU飙高原因
📣读完这篇文章里你能收获到 - VS自带的性能排查工具使用 - CPU排查的分析过程 - 排查经验分享
299 1
『性能调优』在开发环境中,.NET如何排查CPU飙高原因
|
数据库 容器
.NET Core2.1下采用EFCore比较原生IOC、AspectCore、AutoFac之间的性能
一、前言  ASP.NET Core本身已经集成了一个轻量级的IOC容器,开发者只需要定义好接口后,在Startup.cs的ConfigureServices方法里使用对应生命周期的绑定方法即可,常见方法如下 services.
2704 0
|
网络架构 Docker 容器
使用.NET Core搭建分布式音频效果处理服务(七)使用Docker压榨性能极限
Docker相信很多朋友都使用过,做微服务比虚拟机还好用。   需要安装的一些东西 ffmpeg: docker pull ffmpeg dotnet: docker pull dotnet 默认全是latest最新即可,具体怎么配置网上搜索一下即可。
1407 0