asp.net 应用程序性能统计类
绝大多数关于asp.net应用程序性能统计类的信息，最近整理到了一个综合性的文档中叫做“改进.net应用程序性能和扩展性”。以下的表格描述了一些监控和优化asp.net应用程序性能的重要的统计类，包括报表服务。
性能对象 | 统计类 | 实例 | 描述 |
处理器 | % 处理器时间 | __total | % 处理器时间监控了web服务器计算机的cpu利用情况。低cpu利用或者无法增加cpu利用，不考虑客户负荷，意味着在你的web应用程序上有资源和锁之间的竞争。 |
进程 | % 处理器时间 | aspnet_wp 或者 w3wp，依赖于iis的版本 | asp.net处理所消耗的处理器时间百分比。当你将在标准负荷下的性能和以前捕获的基线进行比较，在统计类中减少了说明更低的处理器需求和改进了扩展性。 |
进程 | 工作规定 | aspnet_wp 或者 w3wp，依赖于iis的版本 | asp.net激活时使用的内存数量。虽然应用程序开发人员能最好地控制应用所需的内存数量，但是管理人员通过调整会话超时周期可以明显地影响内存占用数量。 |
进程 | 私有字节 | aspnet_wp 或者 w3wp，依赖于iis的版本 | 私有字节是目前内存的字节大小，由本处理占用的，不可以和其他处理进行共享。一些瓶颈会导致工作处理占用比期待更多的内存。突然出现了统计类跌到0说明asp.net应用程序开始重启，由于无法预料的问题。为了校验，监控asp.net应用程序重启。 |
asp.net 应用程序 | 请求/秒 | __total | 允许你核实请求是按最快的速度进行处理的。如果每秒请求的数量少于每秒请求产生的数量，队列就产生了。说明已经超出了最大的请求数。 |
asp.net 应用程序 | 错误统计 | __total | 在执行http请求期间发生的总的错误数。包括所有的转化，编译，和运行时错误。统计类是这些错误的汇总。一个良好功能的web 服务器不应该产生许多错误。如果在asp.net web应用程序上发生了错误，他们的出现可能使实际结果出现偏差。 |
asp.net | 请求执行时间 | 以毫秒来显示时间，是产生上一个请求页面到传输到用户的时间。这个统计类的时间将会大一点，是一个从开始到结束请求时间更综合的测量。如果统计类显示比基线更低的平均值，那么扩展性和应用程序的性能都提高了。 | |
asp.net | 应用程序重启 | web服务器在生命周期内重启的次数。每个应用程序onend事件和应用程序重启同时增加。 应用程序重启一般发生在改变web.config文件，改变了应用程序的in目录，或者在web forms pages有太多的更改。在统计类中有无法预料的增加，说明一些预想不到的问题导致web应用程序关闭 在这种情况下你应该调查事故原因。 | |
asp.net | 请求排队 | 在队列中等待服务的请求数量。 当队列中有请求时，说明请求数量超出了能处理的请求最大值。默认情况下该统计类的值是5,000。你可以在机器的config文件中改变该值。 | |
asp.net | 工作进程重启 | 在服务器上，工作进程重启的次数。如果工作进程出现意外的失败或者故意循环，可以重启工作进程。当统计类出现了不可意料的增加，你应该调查原因。 |
除上一个表格中的核心控制外，以下的表格的性能统计类提供了增加值，当你试图诊断特定的asp.net应用程序性能问题。
性能对象 | 统计类 | 实例 | 描述 |
asp.net应用程序 | pipeline instance count | __total | 特定asp.net应用程序的请求管道数量。由于仅仅有一个执行线程可以在管道内运行，该数据给出了并发请求最大的数量。在绝大多数情况下，当低于负荷时该数据最好低一点，说明处理器利用良好。 |
.net clr exceptions | # of exceps thrown | 显示在应用程序中的抛错数。无法意料的增加可能出现了性能问题。仅仅存在错误不是有必要关心的原因，因为一些代码路径依赖于正常运行的抛错，如httpresponse。重定位方式通过抛出无法捕获的错误，threadabortexception。这对跟踪asp.net应用程序更有效。通过错误总的统计类来决定应用程序是否产生了无法预期的错误。 | |
系统 | context switches/ sec | 衡量线程上下文在web服务计算机上通过所有处理器转换的比率。如果统计类值过高，说明通过线程，在用户和核心模式之间有锁或者转换竞争。通过简单的工具来进行深入调查，应该被授权。 |
报表服务性能统计类
报表服务包括它自己的性能统计类和资源消耗。在windows性能监控工具上出现了两个对象，使你能监控实例和部件活动的状态：msrs 2005 web服务和msrs 2005 windows 服务对象。msrs 2005 web服务性能对象包括一个统计类集，用来跟踪报表服务处理。
当asp.net停止web服务时，这些统计类都需要重新设置。下面这个表提供了统计类清单，这些统计类可用来监控报表服务器性能，同时也对目标做了描述。
性能对象: rs web 服务
统计类 | 描述 |
活动的会话 | 活动的会话数。这个统计类提供了所有没有超期的浏览会话数。这不是同时进行请求的数目，该数据存储在reportservertempdb数据库中。 |
缓存命中数/秒 | 重新从目录中检索到的每秒报表请求数。当该值增加了，而内存缓存的命中率却没有增加，意味着报表数据没有经过再处理，但是页面进行了重新显示。在联合内存缓存hits/sec时，利用这个统计类决定用于缓存、磁盘或者内存的资源是否充足。 |
缓存命中失败数/秒 | 从目录中返回报表失败的请求数。联合内存缓存misses/sec时，利用这个统计类决定用于缓存、磁盘或者内存的资源是否充足。 |
第一个会话请求/秒 | 每秒从报表服务器缓存开始的新用户会话数。 |
内存缓存命中数/秒 | 每秒从内存缓存中重新检索报表的次数。内存缓存是报表服务缓存的一部分，它存储了在内存或者临时文件中的显示报表。这将为请求提供最好的性能，因为没有处理的必要。当内存缓存被用时，报表服务器不能为了缓存内容而查询sql server。 |
内存缓存未命中数/秒 | 报表不能从内存缓存中重新检索的每秒次数。 |
下一个会话请求/秒 | 每秒能进行的下一个会话请求数 |
报表请求 | 被报表服务器激活和被处理的报表数 |
报表执行/秒 | 每秒执行的报表数。这个统计类提供了报表量的统计。 利用这个值可以和从缓存中执行报表请求的时间进行对比。 |
请求/秒 | 每秒向报表服务器发出的请求数。这个统计类跟踪了由报表服务器处理的所有类型的请求。 |
总的缓存命中数 | 从服务启动之后报表请求总的缓存命中数。当停止web服务时，该统计类将重新设置。 |
总的缓存未命中数 | 从服务启动之后报表请求总的缓存未命中数。当停止web服务时，该统计类将重新设置。可以据此判断磁盘空间和内存是否充足。 |
总的内存缓存命中数 | 从服务启动之后报表请求总的内存缓存命中数。当停止web服务时，该统计类将重新设置。内存缓存是缓存的一部分，在cpu内存中存储报表。当内存缓存被用时，报表服务器不能为了缓存内容而查询sql server。 |
总的内存缓存未命中数 | 从服务启动之后报表请求总的内存缓存未命中数。当停止web服务时，该统计类将重新设置。 |
总的处理失败数 | 从服务启动之后报表请求总的处理失败数。当停止web服务时，该统计类将重新设置。处理失败可能源自报表处理器或者任何的扩展。 |
总的请求执行数 | 从服务启动之后成功执行报表的数目。 |
总的请求数 | 从服务启动之后总的请求数。 |
rs windows服务性能对象包括一个统计类集，用来跟踪报表处理，这些处理是通过预定的操作来初始化的。预定的操作包括订阅和交付，报表执行快照和报表历史。当微软工作量不包含任何预定的或者交付的操作时，这些性能统计类列在这里，仅供方便使用。性能对象被用来监控报表服务器windows服务。如果你在一个向外扩展的配置上远行报表服务器，该计算将应用到已选的服务器，而不是整个向外扩展的配置。
当应用程序域循环时，这些统计类要重新设置。以下的表格提供了一系列统计类，这些统计类用来监控预定和交付，还有描述。
统计类 | 描述 |
清空缓存数/秒 | 每秒钟清空缓存的数量 |
缓存命中数/秒 | 缓存报表每秒的请求数 |
缓存未命中数/秒 | 未能从缓存中读取报表的每秒请求数 |
交付数/秒 | 从任何交付范围，每秒交付的报表数 |
事件数/秒 | 每秒处理的事件数。监控的事件包括snapshotupdated 和 timedsubscription。 |
内存缓存命中数/秒 | 每秒从内存缓存中重新检索报表的次数 |
内存缓存未命中数/秒 | 每秒未能从内存缓存中重新检索报表的次数 |
报表请求数 | 由报表服务器处理和激活的报表数。利用这个统计类评估缓存策略。请求明显多于报表执行。 |
报表执行数/秒 | 每秒钟成功执行的报表数 |
快照更新数/秒 | 每秒钟预定更新的快照数 |
总的app域循环数 | 从服务开启后，总的app域循环数 |
总的缓存清空数 | 从服务开启后，总的报表服务器缓存更新数 |
总的缓存命中数 | 从服务开启后，总的从缓存中得到报表的请求数 |
总的缓存未命中数 | 从服务开启后，总的不能从缓存中得到报表的次数。利用这个统计类可以决定是否需要更多的磁盘空间或者内存。 |
总的交付数 | 包括所有的交付数。 |
总的事件数 | 从服务开启后，总的事件数。 |
总的内存缓存命中数 | 从服务开启后，总的从内存缓存中得到的报表数。 |
总的内存缓存未命中数 | 从服务开启后，总的从内存缓存中未能得到的报表数。 |
总的处理失败数 | 从服务开启后，总的报表处理失败数。处理失败的原因可能是报表处理器或者任何扩展。 |
总的被拒绝的线程数 | 总的被拒绝的线程数，由于异步处理和随后的处理在相同的线程里。 |
总的报表执行数 | 总的报表执行数。 |
总的请求数 | 从服务开启后，成功执行报表的数。 |
总的快照更新数 | 从服务开启后，总的快照更新数。 |
如果你对报表服务还有性能争议问题，记下以下性能统计类非常有帮助：
asp.net, asp.net 应用程序, 进程, 系统,内存, 物理磁盘, .net 异常, .net 内存, .net 装载, .net clr locks 和 threads, 和.net clr 数据。
可选的报表服务性能统计类
以下是一个性能统计类集，应用于rs web服务上，但不是默认安装。当执行性能优化时，这些可以给你提供参考。为了实现这些，在命令框执行以下的语句：
installutil.exe /u reportingserviceslibrary.dll，随后是:installutil.exe reportingserviceslibrary.dll
成功执行这个语句后，你首先需要修改你的路径，包含微软.net框架安装时的目录位置。然后执行从目录中执行前面的语句，目录包含了reportingserviceslibrary.dll文件。默认情况下，这是安装在c:program filesmicrosoft sql servermssqlmssql.instancereporting servicesreportserverin里面。这些统计类没有全部列出。
活动数据库连接数 | 在某一时间内的活动数据库连接数。仅仅指连接到报表服务目录的数目。 |
活动数据源连接数 | 在某一时间内的活动数据库连接数。正在运行的报表连接到源数据的连接数。 |
活动线程数 | 当前活动的线程数。在web服务中，它包含了和服务请求相关的线程。在交付服务中，它包含了工作线程、维持和检测线程。 |
字节数 | 为了上一次请求，当显示当前报表时向客户返回的字节数。类似于相应的执行日志入口。 |
行数 | 为了上一次请求，由目前报表返回的行数。类似于相应的执行日志入口。 |
压缩时间 | 为了上一次请求，花费在压缩快照和pdf上的毫秒数。 |
数据源访问时间 | 为了上一次请求，花费在访问报表数据源信息上的毫秒数。包括执行查询和获取结果。类似于相应的执行日志入口。 |
数据库时间 | 为了上一次请求，花费在访问报表服务器目录信息上的毫秒数。 |
处理时间 | 为了上一次请求，花费在报表处理上的毫秒数。这类似于相应的执行日志入口。 |
显示时间 | 为了上一次请求，花费在报表显示上的毫秒数。这类似于相应的执行日志入口。 |
报表服务执行日志
报表服务执行日志是一个额外的为了监控报表服务性能的信息源。日志包括报表信息，报表是由服务器执行的或者通过向外扩展的多个服务器执行的。你可以使用报表执行日志找到多长时间有一次报表请求，什么格式最常用，花费在每个处理阶段上的处理时间百分比。不同于性能监控对象，它不需要当应用程序域循环或者asp.net停止web服务时进行重新设置，执行日志的结果保持完好，除非你重新设置它们。
另外一个使用执行日志的好处是，它可以更好地知道报表花费了多少检索时间，多少处理时间，形成请求格式的显示时间。这些细节信息对识别和调试性能瓶颈有着不可估量的价值。
报表执行日志捕获了一下信息：
◆处理请求的报表服务器实例的名字。
◆报表标识。
◆用户标识。
◆用户或者系统的请求类型。
◆显示格式。
◆执行报表的参数值。
◆开始和停止的次数表示了报表进程的持续时间。
◆知道报表花费在检索，处理，形成请求格式的时间百分比。
◆报表执行源 (1=实况, 2=缓存, 3=快照, 4=历史数据)。
◆状态，成功或出错的代码，如果多个错误并发，仅能记录第一个错误。
◆显示报表的字节大小。
◆查询返回的数据行数。
关于报表执行的报表服务日志数据以表格的形式存在目录中。这个表不能提供自己完整的信息，也不能给出用户能明白的格式数据。为了查看报表执行数据，你首先应该运行集成服务包，它来自报表服务样例。然后，从执行日志抽取数据并放到一个表结构中，这样就容易被查询。
这是首先的、值得推荐的方式，因为在目录内部的表结构可能会随着产品的版本而改变。
如果需要更多的关于如何安装，配置，从报表服务器执行日志访问数据等信息，请查询在线的“querying and reporting on report execution log data”一文。
新闻热点
疑难解答
