若是须要在一台计算机上监视多个 Report Server 实例,能够同时或单独监视这些实例。选择要包括的实例是计数器添加过程的一部分。有关使用 Windows 附带的性能工具的更多信息,请参见微软 Windows 产品文档。数据库
若要访问性能工具浏览器
• | 从“开始”菜单上选择“运行”。缓存 |
• | 在“打开”文本框中输入“perfmon”,而后单击“肯定”。性能优化 |
• | 在性能监视器工具中,在左侧窗格里选择 System Monitor 对象,而后右击“性能”图表。服务器 |
• | 选择“添加计数器”。并发 |
如今,能够开始选择这些对象和要监视的计数器了。异步
有关 ASP.NET 应用程序性能计数器的大部分信息最近已被合并到一个题为“改善 .NET 应用程序的性能和伸缩性”的综合文档中。下表描述了一些可用于监视和优化 ASP.NET 应用程序(包括 Reporting Services)性能的重要计数器。工具
性能对象 | 计数器 | 实例 | 描述 |
Processor(处理器)性能 |
% Processor Time(处理器时间百分比)优化 |
__Total |
“% Processor Time”监视运行 Web 服务器的计算机的 CPU 利用率。低 CPU 利用率或者没法最大化 CPU 利用率(不管客户端负载为多少)都代表 Web 应用程序中存在对资源的争用或锁定。 |
Process(进程) |
% Processor Time(处理器时间百分比) |
aspnet_wp 或 w3wp(具体状况视 IIS 版本而定) |
由 ASP.NET 工做进程所使用的处理器时间所占的百分比。在将标准负载状况下的性能与先前捕获的基准进行对比时,若是此计数器的值出现降低,则说明下降了对处理器的需求,所以也提升了伸缩性。 |
Process(进程) |
Working Set(工做集) |
aspnet_wp 或 w3wp(具体状况视 IIS 版本而定) |
由 ASP.NET 主动使用的内存数量。虽然应用程序开发人员对应用程序使用的内存数量拥有最大的控制权,但系统管理员也可经过调整会话的超时期限来显著影响这一点。 |
Process(进程) |
Private Bytes(专有字节) |
aspnet_wp 或 w3wp(具体状况视 IIS 版本而定) |
Private Bytes 是当前分配给该进程且不能由其余进程共享的内存数量(以字节计)。不时出现的尖峰代表某些地方存在瓶颈,会致使工做进程继续持有再也不须要的内存。若是此计数器忽然降低为接近 0 的值,则可能表示 ASP.NET 应用程序因为没法预料的问题进行了重启。为了验证这一点,请监视“ASP.NET Application Restarts”计数器。 |
ASP.NET Applications(ASP.NET 应用程序) |
Requests/ Sec(每秒的请求数) |
__Total |
容许您检验请求的处理速度是否于发送速度相适应。若是每秒请求数的数值低于每秒产生的请求数,则会出现排队现象。这一般意味着已经超过了最大请求速度。 |
ASP.NET Applications(ASP.NET 应用程序) |
Errors Total(总错误数) |
__Total |
在执行 HTTP 请求期间发生的错误总数。包括任何分析器、编译或运行时错误。此计数器是“Errors During Compilation”(编译错误数)、“Errors During Preprocessing”(预处理错误数)和“Errors During Execution”(执行错误数)计数器的总和。运转正常的 Web 服务器不该产生任何错误。若是错误发生在 ASP.NET Web 应用程序中,它们的存在可能会让实际的吞吐量结果产生误差。 |
ASP.NET |
Request Execution Time(请求执行时间) |
|
显示了呈现所请求页面并将其传送给用户所需的时间(以毫秒计)。跟踪此计数器一般要比跟踪页面呈现时间效果更好。此计数器能够更全面地衡量从开始到结束的整个请求时间。在与基准进行对比时,若是此计数器的平均值较低,则说明应用程序的伸缩性和性能均获得了改善。 |
ASP.NET |
Application Restarts(应用程序从新启动) |
|
应用程序在 Web 服务器生存期间发生从新启动的次数。每次发生 Application_OnEnd 事件时,应用程序的从新启动次数都会增长。应用程序进行从新启动的缘由多是:更改了 Web.config 文件、更改了存储在应用程序的 \bin 目录下的程序集、或者 Web Forms 页面中发生了太多的更改。若是此计数器的值出现意料以外的增长,说明某些不可预知的问题致使 Web 应用程序被关闭。在这种状况下,应该认真调查问题缘由。 |
ASP.NET |
Requests Queued(排队的请求数) |
|
在队列中等待服务的请求数。若是此数字随着客户端负载的增长而呈现线性的增加,则说明 Web 服务器计算机已经达到了它可以处理的并发请求极限。此计数器的默认最大值为 5,000。您能够在计算机的 Machine.config 文件中更改此设置。 |
ASP.NET |
Worker Process Restarts(工做进程从新启动) |
|
工做进程在服务器计算机上从新启动的次数。若是出现意料以外的故障或者被有意回收,则工做进程会从新启动。若是此计数器的值出现意料以外的增长,应认真调查问题缘由。 |
除了上表中介绍的这些核心监视要素以外,在您试图诊断 ASP.NET 应用程序具备的特定性能问题时,下表中的性能计数器也可对您有所帮助。
性能对象 | 计数器 | 实例 | 描述 |
ASP.NET Applications(ASP.NET 应用程序) |
Pipeline Instance Count(管线实例计数) |
__Total |
指定 ASP.NET 应用程序的活动请求管线实例的数量。因为只有一个执行线程能够在管线实例内运行,因此此数值反映了为特定应用程序处理的并发请求的最大数量。大多数状况下,在存在负载的状况下此数值较低为佳,这代表处理器获得了很好的利用。 |
.NET CLR Exceptions(.NET CLR 异常) |
# of Exceps Thrown(引起的异常数) |
|
显示应用程序中引起的异常数。若是此数值出现意料以外的增长,说明可能存在性能问题。若是仅仅存在异常,则并不须要担忧,由于异常对于某些代码路径来讲是正常工做的一部分。例如,HttpResponse.Redirect 方法经过引起一个不可捕获的异常 ThreadAbortException 来完成工做。一样,对 ASP.NET 应用程序跟踪此计数器也更加有用。使用“Errors Total”计数器肯定该异常是否将致使应用程序出现意料以外的错误。 |
System(系统) |
Context Switches/ sec(每秒的上下文切换次数) |
|
测量 Web 服务器计算机上全部处理器切换线程上下文的速度。若是此计数器的值很高,可能表示对锁的争用频繁发生,或者在线程的用户模式和内核模式之间切换频繁。使用采样优化程序和其余工具执行进一步调查可证明上述猜想。 |
Reporting Services 包括一组它本身的性能计数器,用于收集有关报告处理和资源消耗方面的信息。可经过 Windows 性能监视器工具中出现的两个对象来监视实例和组件的状态和活动:MSRS 2005 Web Service 和 MSRS 2005 Windows Service 对象。
MSRS 2005 Web Service 性能对象包括一组用来跟踪 Report Server 处理过程的计数器,这些处理过程一般经过在线交互式报告浏览操做而引起。这些计数器在 ASP.NET 中止该 Web 服务后被重设。下表列出了可用于监视 Report Server 性能的计数器,并描述了它们的目的。
性能对象:RS Web Service
计数器 | 描述 |
Active Sessions(活动会话数) |
活动会话的数量。此计数器反映了还没有过时的全部浏览器会话总数。这并非同时处理的请求数,而是存储在 ReportServerTempDB 数据库中的会话数量。 |
Cache Hits/Sec(每秒缓存命中次数) |
每秒从目录中取得的报告请求的数量。若是此值增长,而“Memory Cache Hits”的值不增长,则说明报告数据没有被从新处理,可是页面被从新呈现。将此计数器与 Memory Cache Hits/Sec 计数器一同使用,能够肯定用于缓存、磁盘或内存的资源是否充足。 |
Cache Misses/Sec(每秒缓存未命中数) |
每秒未能从目录中(与内存中相对)返回报告的请求数量。将此计数器与 Memory Cache Misses/Sec 计数器一同使用,能够肯定用于缓存、磁盘或内存的资源是否充足。 |
First Session Requests/Sec(每秒的首次会话请求数) |
每秒中从 Report Server 缓存中启动的新的用户会话数量。 |
Memory Cache Hits/Sec(每秒内存缓存命中数) |
每秒中从内存中的缓存里取得报告的次数。内存中缓存是 Reporting Services 缓存的一部分,用于在内存或临时文件中保存已呈现过的报告。这样能够为请求提供最佳的性能,由于无需执行任何处理工做。若是使用内存中缓存,报告服务器将不会经过查询 SQL Server 来得到缓存的内容。 |
Memory Cache Misses/Sec(每秒内存缓存未命中数) |
每秒中未能从内存中的缓存里取得报告的次数。 |
Next Session Requests/Sec(每秒的下一次会话请求) |
每秒在现有会话中请求打开报告的次数。 |
Report Requests(报告请求) |
当前处于活动状态而且将由 Report Server 进行处理的报告数量。 |
Reports Executed/Sec(每秒执行的报告数) |
每秒成功执行的报告的数量。此计数器提供了有关报告处理量的统计信息。综合使用此计数器和 Request/Sec,比较可从缓存中返回的报告请求的执行状况。 |
Requests/Sec(每秒的请求数) |
每秒向 Report Server 发出的请求数。此计数器跟踪由 Report Server 处理的全部类型的请求。 |
Total Cache Hits(缓存命中总数) |
自服务启动以来,从缓存中得到报告的请求总数。此计数器在 ASP.NET 中止该 Web 服务后被重设。 |
Total Cache Misses(总的缓存未命中数) |
自服务启动以来,不能从缓存中得到报告的总次数。此计数器在 ASP.NET 中止该 Web 服务后被重设。可以使用此计数器肯定磁盘空间和内存是否充足。 |
Total Memory Cache Hits(总的内存缓存命中数) |
自服务启动以来,从内存中缓存里返回的已缓存报告的总数。此计数器在 ASP.NET 中止该 Web 服务后被重设。内存中缓存是在 CPU 内存中存储报告的那部分缓存。若是使用内存中缓存,报告服务器将不会经过查询 SQL Server 来得到缓存的内容。 |
Total Memory Cache Misses(总的缓存未命中数) |
自服务启动以来,针对内存中缓存的缓存未命中总数。此计数器在 ASP.NET 中止该 Web 服务后被重设。 |
Total Processing Failures(处理故障总数) |
自服务启动以来,发生的全部报告处理故障的总数。此计数器在 ASP.NET 中止该 Web 服务后被重设。处理故障可能来自报告处理器,也可能来自任何扩展。 |
Total Reports Executed(执行的报告总数) |
自服务启动以来获得成功执行的报告的总数。 |
Total Requests(总请求数) |
自服务启动以来,向 Report Server 发送的全部请求的总数。 |
RS Windows Service 性能对象包括一组用于跟踪报告处理过程的计数器,这些处理过程是经过预约操做而引起的。预约操做可能包括订阅和交付、报告执行快照以及报告历史。微软的工做负载中并不包含任何预约操做或交付操做,此处列出这些性能计数器仅是便于您进行参考。
可以使用此性能对象监视 Report Server Windows 服务。若是您准备在一个横向伸缩配置中运行 Report Server,那么这些计数器应用于所选的服务器,而不是应用于横向伸缩配置总体。这些计数器在应用程序域回收之时将被重设。下表列出了可用于监视预约和交付操做的计数器,并描述了它们的目的。
性能对象:RS Windows Service
计数器 | 描述 |
Cache Flushes/Sec(每秒缓存刷新次数) |
每秒刷新缓存的次数。 |
Cache Hits/Sec(每秒缓存命中数) |
每秒获取到缓存报告的请求数量。 |
Cache Misses/Sec(每秒缓存未命中数) |
每秒未能从缓存中得到报告的请求的数量。 |
Delivers/Sec(每秒交付数) |
每秒从各类交付扩展交付的报告的数量。 |
Events/Sec(每秒事件数) |
每秒处理的事件数量。被监视的事件,包括 SnapshotUpdated 和 TimedSubscription。 |
Memory Cache Hits/Sec(每秒内存缓存命中数) |
每秒中从内存中的缓存里取得报告的次数。 |
Memory Cache Misses/Sec(每秒内存缓存未命中数) |
每秒中未能从内存中的缓存里取得报告的次数。 |
Report Requests(报告请求数) |
当前处于活动状态而且将由 Report Server 进行处理的报告数量。可以使用此计数器评估缓存策略。向特定呈现扩展提交的请求数。请求的数量可能比执行的报告数量多许多。 |
Reports Executed/Sec(每秒执行的报告数) |
每秒成功执行的报告的数量。 |
Snapshot Updates/Sec(每秒快照更新数) |
每秒报告执行快照的预约更新数量。 |
Total App Domain Recycles(应用程序域回收总数) |
自服务启动以来回收的应用程序域总数。 |
Total Cache Flushes(缓存刷新总数) |
自服务启动以来,Report Server 的缓存更新总数。 |
Total Cache Hits(缓存命中总数) |
自服务启动以来,从缓存中得到报告的请求总数。 |
Total Cache Misses(总的缓存未命中数) |
自服务启动以来,不能从缓存中得到报告的总次数。 可以使用此计数器肯定是否须要更多磁盘空间或内存。 |
Total Deliveries(总交付数) |
由 Scheduling and Delivery Processor 交付的报告总数(对于全部交付扩展)。 |
Total Events(总事件数) |
自服务启动以来发生的事件的总数。 |
Total Memory Cache Hits(总的内存缓存命中数) |
自服务启动以来,从内存中缓存里返回的已缓存报告的总数。 |
Total Memory Cache Misses(总的缓存未命中数) |
自服务启动以来,针对内存中缓存的缓存未命中总数。 |
Total Processing Failures(处理故障总数) |
自服务启动以来,发生的全部报告处理故障的总数。处理故障可能来自报告处理器,也可能来自任何扩展。 |
Total Rejected Threads(被拒绝的线程总数) |
拒绝执行异步处理后在同一线程中做为同步过程在之后进行处理的数据处理线程总数。 |
Total Report Executions(报告执行总数) |
已执行报告的总数。 |
Total Requests(请求总数) |
自服务启动以来获得成功执行的报告的总数。 |
Total Snapshot Updates(快照更新总数) |
自服务启动以来,报告执行快照进行更新的总数。 |
若是您打算排除 Reporting Services 存在的性能问题,记录如下性能计数器一般颇有帮助:ASP.NET、ASP.NET Applications、Process、System、Memory、Physical Disks、.NET Exceptions、.NET Memory、.NET Loading、.NET CLR Locks and Threads 以及 .NET CLR Data。
如下列出了一些适用于 RS Web Service 但在默认状况下并未安装的性能计数器。可是,在执行性能优化工做时,能够经过这些计数器来改善您洞察性能的能力。为实现这个目的,请在命令提示符中执行如下语句:
installutil.exe /u ReportingServicesLibrary.dll
而后再执行:
installutil.exe ReportingServicesLibrary.dll
为了成功执行该语句,您可能首先须要修改您的路径,在路径中包含 Microsoft .NET Framework 的安装目录。在路径修改完毕后,请从包含 ReportingServicesLibrary.dll 文件的目录下执行先前语句。默认状况下,该文件安装在 C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL.instance\Reporting Services\ReportServer\bin 目录下。这些计数器没有进行完全的本地化。
Active Database Connections(活动数据库链接) |
某个时间处于活动状态的数据库链接的数量。只统计指向 Report Server 目录的链接。 |
Active Datasource Connections(活动数据源链接) |
某个时间处于活动状态的数据库链接的数量。只统计由当前运行的报告打开的数据源链接。 |
Active Threads(活动线程) |
当前处于活动状态的线程数量。在 Web 服务中,它包含一些为请求提供服务的线程。在交付服务中,它包含工做线程以及维护和轮询线程。 |
Byte count(字节计数) |
对于上一次请求,在呈现当前报告时向客户端返回的字节数量。这与对应的执行日志条目相相似。 |
Row Count(行计数) |
对于上一次请求,由当前报告返回的行的数量。这与对应的执行日志条目相相似。 |
Time in Compression(压缩时间) |
对于上一次请求,在快照和 PDF 报告压缩上花费的时间(以毫秒计)。 |
Time in data source access(数据源访问时间) |
对于上一次请求,在获取报告的数据源信息上花费的时间(以毫秒计)。其中包括执行查询和取回结果所需的时间。这与对应的执行日志条目相相似。 |
Time in database(数据库时间) |
对于上一次请求,在获取 Report Server 目录信息上花费的时间(以毫秒计)。 |
Time in processing(处理时间) |
对于上一次请求,在报告处理上花费的时间(以毫秒计)。这与对应的执行日志条目相相似。 |
Time in rendering(呈现时间) |
对于上一次请求,在呈现报告上花费的时间(以毫秒计)。这与对应的执行日志条目相相似。 |