Reporting Services 的伸缩性和性能表现规划(转载)
简介
Microsoft? SQL Server? Reporting Services 是一个将集中管理的报告服务器具有的伸缩性和易管理性与基于 Web 和桌面的报告交付手段集于一身的报告平台。Reporting Services 是微软功能全面的商业智能平台的重要组件。
对于许多组织，通过报告提供信息是日常业务操作的一种基本活动。所以，报告系统的性能表现必须确保一致和可预测。随着报告负载的增加，组织必须能够以一种可预期和具有成本效益的方式提高报告能力。
关于本文
本文旨在帮助客户和合作伙伴确定如何面对日益增加的负载，以最佳方式规划、优化和伸缩他们的报告服务实现架构。本白皮书讨论了以下主题：
| • |
不同硬件配置的性能表现和伸缩特性（如纵向伸缩和横向伸缩） |
| • |
报告缓存和文件系统存储对性能的影响 |
| • |
有关 Reporting Services 性能优化的最佳做法 |
| • |
有关运行您自己的性能测试的建议 |
虽然本白皮书关注的目标是 Microsoft SQL Server 2005 Reporting Services，但文中提供的大多数信息也适用于该产品的早期版本。
前提条件
本白皮书并不打算事无巨细地包含有关 Reporting Services 的所有信息。如需获得有关该产品的详细信息，请参见产品文档以及可通过以下地址获得的其他在线资源：http://www.microsoft.com/sql/reporting/.
除 Reporting Services 之外，本文档假设读者已经熟悉以下主题：
| • |
Microsoft SQL Server |
| • |
Internet Information Services (IIS) |
| • |
Microsoft .NET Framework |
有关这些主题的信息可通过以下地址从 MSDN 网站上获得：http://msdn.microsoft.com?
概述
Reporting Services 是基于服务器的全面平台，用于创建、管理和交付基于纸张的传统报告和基于 Web 的互动式报告。在执行报告时，Reporting Services 执行以下基本工作：
| • |
取得要报告的数据 |
| • |
根据报告定义中的指令处理数据 |
| • |
以特定格式呈现报告 |
Reporting Services 还执行支持报告处理的其他工作，例如管理和处理订阅，管理和处理快照和缓存请求，以及提交报告管理请求。
Reporting Services 的工作负载主要来自于以下三种应用情境：
| • |
在线用户对已发布报告的互动式访问 |
| • |
根据预先计划或由事件驱动，通过订阅以电子邮件或文件共享方式交付报告 |
| • |
由在线用户动态创建和执行的特别报告 |
本白皮书集中讨论第一种应用情境，即由在线用户执行已发布报告。这是大多数客户希望增强其伸缩能力的主要工作负载。
交 付订阅报告的优点在于可以预先设定日程安排，因此为您赋予了控制在何时和何处执行处理过程的更强能力。互动式报告则更难于做出规划，因为它很大程度上要取 决于报告的规模和复杂性、并发用户的数量以及报告的呈现格式。在访问互动式报告时，用户还对系统响应速度抱有很高的期望。
利用 SQL Server 2005 Reporting Services，最终用户可使用新的 Report Builder 工具，以交互方式创建和执行报告。创建特别报告为 Report Server 带来的额外负担很难进行量化，因为这要视用户操作的内容及效率而定。特别报告的伸缩性将在本白皮书今后的版本中予以介绍。
本白皮书包含一些通用的性能指南，这些指南是微软在针对不同配置创建和测试交互式报告负载的过程中总结而成的。但是，若要获得能够反映您自身环境的具体性能数字，需要您自己运行性能测试。本白皮书所提供图形和结果的目的仅是帮助用户了解不同配置具有的伸缩特性。
伸缩性和可靠性
系统伸缩性难以定义，因为它经常对不同的人具有不同的含义。之所以如此，是因为人们经常将伸缩性与可靠性放在一起进行讨论。虽然可靠性是任何系统配置都不可忽视的重要考虑事项，但是它的存在是否会对实际的伸缩性造成影响并无法确定。
在 本文中，伸缩性被定义为：在不从根本上改变系统设计或架构的情况下，通过逐步增加系统资源让系统支持更多工作负载的一种能力。理想情况下，随着系统资源的 增加，系统处理工作负载的能力也应随之成比例增加。虽然这听起来很直观，但是实现¡°近乎线性¡±的伸缩性通常十分困难。实际上，系统通常无法实现完美的 线性伸缩。这是由于部署在各种异类系统中的多个应用程序组件间必不可少的管理、协调和沟通工作会带来的大量的开销。
系统可靠性所基于的观点 则与此稍有不同。可靠系统是一种在不出现故障的情况下对不断增加的工作负载进行妥善处理的系统。此外，可靠系统不应随着工作负载的增加而出现崩溃或运行中 止。相反，其性能只应出现缓慢的下降。但是，在压力足够大的情况下，任何系统都可能变得不可用。而可靠系统的独特之处就在于它们能够从这些事件中恢复。
对于为实施 Reporting Services 而进行的容量规划，其成功关键便在于在工作过载和系统平滑处理增加的工作负载之间找到平衡，并籍此建立满足伸缩性要求的可靠系统。
纵向伸缩和横向伸缩
Reporting Services 的灵活设计使得用户既可在单台服务器也可在多台服务器上部署其组件，具体情况则取决于用户的需要和喜好。
开始时，Reporting Services 的用户经常询问应购买单台的大型服务器（纵向伸缩）还是应购买多台小型服务器（横向伸缩）。本白皮书介绍了 Reporting Services 的伸缩特性，在解答用户提出的这个问题的同时帮助他们做出明智决策。
纵向伸缩途径使用一台大型的对称多处理器服务器提供更高的处理能力。与横向伸缩相比，这种方法的优点在于它具有更为轻松的配置和管理体验。纵向伸缩还是一种用于伸缩 SQL Server 关系型引擎和 Analysis Services 的方法。
横向伸缩是 Reporting Services Enterprise Edition 支持的配置方式，也是大多数客户考虑采用的伸缩方式。这主要是由于横向伸缩：
| • |
允许用户根据需要逐步增加或撤除容量 |
| • |
为增加和撤除容量提供了一种非常灵活、易于管理和价格可承受的方法。 |
| • |
允许在多台商用服务器上平衡大量工作负载 |
| • |
提供了一定程度的固有容错能力 |
如 果您决定使用横向伸缩配置方式部署 Reporting Services，应当意识到需要在多台 Report Servers 之间进行协调，让它们都能够访问安装在本地或远程 SQL Server 关系型数据库上的单个 Report Server 目录。有关 Reporting Services 部署选项的更多信息，请参阅位于如下地址的在线文档：http://www.microsoft.com/sql/reporting/ 和 http://technet.microsoft.com/sql.
Reporting Services 组件
为了全面理解伸缩性，首先需要理解 Reporting Services 的体系结构（如图 1 所示）和它的各个组件。
图 1：Reporting Services 的体系结构
查看大图
Reporting Services 从逻辑上可划分为三层（如表 1 所示）。
表 1
| 组件 | 功能 | ||||||||
|
Report Server |
一个具备如下功能的 Web 服务：
Report Server 还包括一个负责日程计划和批操作的 Windows 服务。本白皮书未讨论该应用情境的伸缩性问题。 |
||||||||
|
Report Server Catalog |
以下两个 SQL Server 数据库来自该目录：
该目录可与 Report Server 驻留在同一物理系统上，也可位于不同系统上（远程目录）。 |
||||||||
|
客户端应用程序 |
客 户端应用程序通过 SOAP Web 服务和 URL 请求访问服务器。Report Management 工具和 Report Viewer 应用程序是包含在 Reporting Services 之中的客户端应用程序。Microsoft® Visual Studio® 2005 为在客户端系统中嵌入报告提供了 Report Viewer。Report Builder 是用于特别报告的报告制作工具。许多第三方软件厂商还提供它们自己的客户端应用程序。 |
伸缩指南
本部分内容介绍 Reporting Services 的基本配置选项，并描述它们对性能和伸缩性的影响。本部分内容的目标是帮助读者找出满足自身的性能和负载需要的有效 Reporting Services 配置，并且回答如下问题：
| • |
您应该考虑在远程计算机上承载目录吗？ |
| • |
对 Report Server 进行纵向伸缩和增添其他 Report Server 这两种方法哪一种更佳？ |
| • |
对于配备四颗处理器的 Report Server，哪一种配置方式最佳？ |
虽然微软对不同配置执行的测试均在施加特定报告负载的情况下得出了结果，但您的实际性能需求应视您的自身环境所特有的各项因素而定。这些因素包括：
| • |
并发用户的数量 |
| • |
所产生报告的大小和复杂性 |
| • |
按需生成报告还是通过订阅生成报告 |
| • |
实时生成报告还是缓存报告 |
后文中的测试结果仅用于确定各种不同配置的相对性能和伸缩特性。请注意，原始指标（例如每秒的页面浏览量）与您的环境和应用情境不同。我们的重点在于这些指标随着向环境分配或增添资源而取得的相对改善。本白皮书后面的章节为您创建自己的性能基准提供了操作指南。
本地配置和远程配置
微软测试了两种本地配置，在同一台服务器上运行 Report Server 及其目录。
在 本地配置方式中，SQL Server 关系型数据库将与 Report Server 争夺可用的计算机资源。如果有足够的资源，将不会出现任何问题。您可能应考虑将最大数量的内存和最多数量的处理器设置为由 SQL Server 数据库引擎使用，以减少它与 Reporting Services 间的资源争用。有关更多信息，请参见附录 A。用户还可选择图 2 中展示的配置，因为它仅需一份 SQL Server 许可证。
作为对比，图 3 中展示的远程目录实现方式需要将 Reporting Services 组件分布在两台物理服务器上。第一台服务器承载 Report Server 引擎，而第二台则以远程方式承载目录。
图 3：远程目录实现方式
查看大图
远程配置方式消除了 Report Server 和承载目录的 SQL Server 之间对计算机资源的争夺。但是，您必须在 Report Server 和目录服务器间提供足够的网络带宽。
纵向伸缩和横向伸缩
在将目录分隔到其他系统中后，可以选择通过增加处理器来对 Report Server 执行纵向伸缩，也可以通过增加计算机来执行横向伸缩。图 4 描述了使用多台 Report Server 访问单个目录的横向伸缩配置。
图 4：使用多台 Report Server 访问单个目录的横向伸缩配置方式
查看大图
通 常，横向伸缩配置方式使用一台远程关系型数据库服务器，该服务器用于承载目录，并且与所有 Report Server 节点均分开布置。虽然可将目录放在其中一个 Report Server 节点上，但我们不推荐采用这种配置方式，因为数据库服务器将与 Report Server 争夺资源。
4 颗处理器的横向伸缩配置方式使用 2 台 Report Server（每台服务器配备 2 颗处理器）访问远程目录。8 处理器的横向伸缩配置方式使用 4 台配备 2 颗处理器的 Report Server。因此，横向伸缩配置不仅处理器数量会成倍增加，而且内存和网络带宽也同样会成倍增加。
本地目录和远程目录性能比较
在伸缩性规划中需要首先决定的事情之一便是：是在与 Report Server 相同的系统上承载 Report Server 目录（本地模式），还是分开单独承载目录（远程模式）。
在本地模式中，一台物理计算机同时承载 Report Server 和 Report Server 目录（一个 SQL Server 实例）。该目录独立于报告数据的源数据库，此数据库通常位于其他服务器上。
单台计算机的设置方式是最简单的实现方式，从许可证的观点看，也是较为便宜的配置方式，但是它仍然具有几个缺点。最重要的是，将目录移动到远程服务器是朝横向伸缩配置方式迈出的第一步。本文的以后部分将对此进行讨论。
在回答向本地实现方式添加处理器和分离出目录这两种方式哪一种较佳这个问题时，我们使用如下系统配置进行了测试：
| • |
配备 2 颗处理器的 Report Server，本地目录（2 处理器） |
| • |
配备 2 颗处理器的 Report Server，远程目录（远程 2 颗处理器） |
| • |
配备 4 颗处理器的 Report Server, 本地目录（4 处理器） |
| • |
配备 4 颗处理器的 Report Server，远程目录（远程 4 颗处理器） |
测试结果揭示了几个很有意思的事实，为究竟应首先纵向伸缩处理器还是应首先分隔报告目录这个问题提供了答案。
| • |
对于使用 2 颗处理器的系统，本地和远程实现方式在轻负载情况下的性能表现大致相同。 |
| • |
相比于 2 颗处理器的本地系统，4 颗处理器的本地系统在每秒处理的请求数这一指标上具有较好的表现，但是并不像 4 颗处理器的远程系统那样实现了性能翻番。 |
表 2 展示了四种配置方式的峰值处理能力（即性能保持在等于 30 秒的阀值之上时能够处理的最大会话数量）的比较结果。
表 2
| 每秒的平均请求数 | 峰值会话数 | |
|
2 处理器（本地） |
基准 |
基准 |
|
2 处理器（远程） |
-10% |
基准 |
|
4 处理器（本地） |
53% |
17% |
|
4 处理器（远程） |
100% |
117% |
从 2 处理器的本地实现方式切换到 2 处理器的远程实现方式本身对服务器能够支持的峰值会话数量不会产生实质性的影响。在吞吐量方面会有一点下降，因为通过网络传输数据会产生一定的开销。
在更高工作负载的情况下，成倍增加本地目录实现方式上的处理器数量（从 2 颗处理器的本地实现到 4 颗处理器的本地实现）实际并不能将可用资源提高两倍。它只能适度提高峰值会话数量，并在每秒处理的请求数方面有 53% 的改进。
但是，在远程目录实现方式中，成倍增加处理器（从 2 颗到 4 颗）可提供线性的伸缩能力。在 4 颗处理器的情况下，峰值请求数量的成倍增加还有甚于峰值会话数量的成倍增加。
关键点
| • |
如果您正在运行 2 颗处理器的本地系统，将目录分隔到其他服务器上对系统整体性能带来的提升最少。 |
| • |
分隔目录会为管理和监视这样的工作带来便利，因为系统不再需要在 Report Server 和数据库进程间分配资源。 |
| • |
如果您正在运行 4 颗处理器的本地系统，将目录分隔到其他服务器会显著提升系统的性能。 |
| • |
对于打算提高伸缩性的系统，远程目录实现方式是朝横向伸缩配置方式迈出的第一步。 |
纵向伸缩
本 部分内容讨论在远程目录配置方式中通过增加处理器数量（纵向伸缩）来提升系统的容量和性能。在本例中，纵向伸缩是从 2 颗处理器的远程系统切换为 4 颗处理器的远程系统。在以下测试中，当响应时间超过预先定义的 30 秒阀值之后便视为达到了极限，这个时间对于大多数用户来说似乎都是无法忍受的。
表 3
| 每秒的平均请求数 | 最大会话数量 | 每分钟的页面浏览量 | |
|
2 处理器（远程） |
10.71（基准） |
600（基准） |
604（基准） |
|
4 处理器（远程） |
23.91 (123%) |
1300 (117%) |
1327 (120%) |
每秒的平均请求数
在高用户负载情况下，4 处理器系统每秒可以处理的请求数显然远远大于 2 颗处理器的远程系统。在远程目录实现方式中，成倍增加处理器的数量可以使得每秒的平均请求数稍稍高于原先的两倍。
最大会话数量
4 处理器的远程配置方式可以支持的最大会话数量超过了 2 颗处理器的远程实现方式所支持最大会话数量的 2 倍。
每分钟页面浏览量
每分钟页面浏览量这一指标考察了页面生成能力。在远程目录实现方式中，通过将处理器数量从 2 成倍增加到 4，可以在高负载情况下将页面浏览量提升为原先的 120%。
关键点
| • |
在将报告目录分隔到其他系统后，将处理器数量从 2 成倍增加到 4 基本上可将 Reporting Services 的处理能力成倍增加，同时不会降低系统的响应速度。 |
| • |
仅针对将处理器数量从 2 增加到 4 的情况进行了测试。以后的测试将考察使用更多处理器来优化系统的情况。 |
横向伸缩
本部分内容考察横向伸缩配置对容量和性能的影响。在微软进行的测试中，Report Servers 忠实地复制了 2 颗处理器远程目录实现方式中的服务器配置。因此，横向伸缩服务器的数量加倍，而所有系统资源（内存、存储和网卡）的数量则翻了四倍。
如果将 2 颗处理器的远程实现方式的系统处理能力与 4 颗或 8 颗处理器的横向伸缩配置进行对比，使用横向伸缩配置的系统可以提供近乎线性的伸缩能力。下表总结了 4 颗和 8 颗处理器的横向伸缩配置相对于作为基准的 2 颗处理器远程系统在各方面取得的进步。
表 4
| 峰值页面浏览量/小时 | 最大并发会话数 (11/14/2005) | |
|
2 处理器（远程） |
10.71（基准） |
600（基准） |
|
2 X 2 处理器（远程） |
23.87 (210%) |
1300 (216%) |
|
4 X 2 处理器（远程） |
45.18 (378%) |
2500 (416%) |
比较每秒的峰值平均请求数以及支持的峰值会话数，2 X 2 处理器的横向伸缩配置方式提供了优于 2 颗处理器远程实现方式的线性伸缩能力。
如果仅比较各种横向伸缩实现，从 2 X 2 处理器的横向伸缩转移到 4 X 2 处理器的横向伸缩不会提供真正线性的伸缩能力。但是，它也可显著提升处理能力，每秒处理的请求数增加了 89%，而支持的峰值会话数则提高了 92%。
关键点
| • |
横向伸缩途径是一条极具成本效益的途径，可在无需大量硬件投入的情况下极大提升系统容量。 |
| • |
如果您预计对 Reporting Services 的需求将持续增加，那么横向伸缩是根据需要增加更多容量的一种灵活方法。 |
纵向伸缩和横向伸缩比较
纵向伸缩和横向伸缩应用方案的直接比较可以通过比较 4 处理器的远程目录和 4 处理器的横向伸缩的容量来进行。在第一种情况下，四颗处理器位于同一台 Report Server 上，而横向伸缩则使用两台配备了 2 颗处理器的 Report Servers。
测试结果表明，两种实现方式之间的差别有限，在每秒的平均请求数和支持的峰值会话数方面它们都旗鼓相当。
横向伸缩在所有节点上总共使用了 8 GB 内存，而 4 处理器的远程系统则使用了 4 GB 内存。
在 同样会话数的情况下，4 处理器系统的系统响应时间方面也不落下风。4 处理器的横向伸缩配置在响应时间方面稍占优势。由于在 Reporting Services 部署中，我们对 ASP.NET 应用程序进行了仔细调较以充分利用横向伸缩配置中价格便宜的硬件设备，这个结果在我们的预料之中。
关键点
如 果您已经拥有一个 2 处理器的远程目录系统，并且必须将其处理能力翻番，将该系统纵向伸缩到 4 处理器的 Report Server 或横向伸缩为两台 Report Servers 都是可行的。虽然转移到横向伸缩配置要求您转移到 Reporting Services Enterprise Edition，但在获得能力提升之外还可获得其他众多益处。这些益处包括：
| • |
处理器数目较少的服务器价格与大型的 SMP 服务器相比较为低廉。 |
| • |
其他计算机可以利用专用的内存地址空间，而无需转移到 64 位系统。 |
| • |
利用增加服务器而不是升级现有服务器来提升能力的做法具有更短的停机时间。 |
| • |
使用多台报告服务器的做法具有更出色的可用性，如果某台服务器发生故障，整个系统仍然可以继续响应请求。 |
| • |
可以轻松地将横向伸缩扩展到 6、8 或 10 颗处理器。通常，在伸缩至 8 颗处理器后，SMP 服务器的性能增长将后继乏力。 |
使用 64 位处理器
SQL Server 2005 Reporting Services 支持 64 位处理器，包括 Intel Itanium2 处理器以及 AMD 和 Intel 的 x64 架构。在 x64 系统上，Reporting Services 既可运行于本机 64 位模式，也可以运行于 32 位的 Windows on Windows (WOW) 子系统上。
通常，在具有相同速度的处理器上运行 64 位系统不会提高报告的吞吐量。相反，从中获得主要好处是用户可以查看和导出大型报告的输出结果。当工作负载提高时，可以在 64 位计算机上获得更大吞吐能力，因为对内存的争用减少了，而且垃圾回收操作的频率也显著降低。在撰写本白皮书之时，微软无法全面测试这些平台，但是计划在本 文档的未来版本中增加相关测试结果。
报告缓存和存储
影响 Reporting Services 实现方式的性能和容量的一大因素便是：用户是通过从源系统中取得数据来实时生成报告，还是使用缓存或快照数据生成报告。本节内容介绍了一些选项以及这些选项对性能造成的潜在影响。
缓存实例
Report Server 有两级缓存：
|
1. |
当 Report Server 生成报告时，它从 Report Server 目录中取得报告定义并从数据源获取报告数据。然后，它创建一份临时报告格式，该报告保存在会话缓存中并写入 ReportServerTempDB 数据库。它使用该版本（缓存实例）创建和呈现最终的报告。 对于完全“实时”报告，它会对每份报告重复此过程。但是，也可以将对已处理过的报告的后续请求定向到缓存实例。这样可显著缩短取得数据和创建报告所需的时间。 |
|
2. |
Report Server 还会尝试对内存中或文件系统的临时目录下的缓存（或快照）报告的输出格式进行缓存。如果请求的结果在输出缓存中找到，便可以同时绕过处理和呈现步骤，因此 可实现非常优异的性能。有关如何确定所使用缓存的类型的更多信息，请参见有关性能计数器的附录 B。 |
缓存最终会过期，并因此导致 Report Server 收集新鲜的数据。可根据预定义的时间间隔、日程安排（特定于报告或共享）或强制过期来控制缓存过期时间。
缓存报告对存储区会产生影响，虽然 SQL Server 2005 Reporting Services 以很紧凑的格式保存数据并且对数据进行了压缩。在确定所要维护的缓存或快照映像的数量时，请考虑以下因素：
| • |
创建缓存实例时应用的查询参数。如果您需要一份带有不同查询参数的报告，Reporting Services 将生成另外一个缓存实例。 |
| • |
查询（过滤器）中未使用的报告参数可以用来创建不同于缓存实例的报告版本。 |
报告快照
快照指的是以更加持久的方式保存的同一份临时报告格式。例如，快照可以保存在 Report Server 目录中，而不是保存到 ReportServerTempDB 数据库。此外，目录还可保有作为报告历史的多个临时版本，因此允许用户在这些版本中做出选择。
SQL Server 2005 Reporting Services 自动对目录中的快照进行压缩。也可以将快照映像保存到本地文件系统中。
以下章节重点介绍了使用缓存实例、压缩快照以及文件系统存储三种方式对性能的映像。
缓存实例
提高 Reporting Services 部署的容量和伸缩能力的一种方法便是：避免使用实时数据来执行报告。如果能达到相同的目的，那么可以转而使用缓存数据来执行报告。
图 5 中的图形显示了检索、处理和呈现一个包含 150 行数据的报告所花费的时间（包括针对实时数据和缓存数据的两种结果）。
图 5：150-K 行的简单报告的时间计算结果
查看大图
综合来看，这些数字表明：对 Reporting Services 使用实时数据时，需要的时间是使用缓存数据的 2.61 倍。返回大量实时数据的报告所需的资源远远超出使用缓存数据的报告。
在系统使用高峰的几个小时内，要求最终用户避免运行实时报告是不切实际的。用户经常不会意识到运行这样的报告会对系统性能和其他系统用户造成何种影响。为了提高系统容量和响应速度，一些可以考虑传达给用户的“好公民”做法包括：
| • |
尽可能避免让报告检索或执行大量实时数据。转而使用缓存数据。 |
| • |
如果无法完全避免使用实时数据，至少试着限制这种报告的运行数量，尤其是在高峰时段。 |
| • |
如果可以使用缓存数据生成报告，可以将这些报告设定为在非高峰时段刷新缓存，以避免影响其他用户。 |
经过压缩的快照存储
在 SQL Server 2005 Reporting Services 中，管理员们可以指定快照数据的存储位置和存储方式。
使用快照能够显著改善报告性能，但是会占用数据库的存储空间。为了在存储空间和性能之间求得平衡，Reporting Services 提供了一个由系统属性控制的压缩选项。默认设置是对快照数据和报告定义进行压缩。也可以关闭压缩功能。
例如，在一个 20,000 行的报告中，SQL 的快照压缩功能可以将快照大小降低 20%。更小的体积不仅意味着可节省 Report Server 目录中的大量存储空间，而且还能极大降低 Report Server 和目录间的网络流量。
文件系统存储
用于存储快照的另一个选项是：使用文件系统 (FS) 存储。此设置不受 SQL 压缩选项的影响，因为数据保存在文件系统中。
FS 快照存储非常适用于 Reporting Services 的远程目录和横向伸缩部署方式。如果启用了 FS 存储，快照数据可以存放在 Report Server 的本地文件系统中。这使得 Report Server 可以避免为支持会话和报告请求而往返于目录。
可以通过更改 RSReportServer.config 文件中的 WebServiceUseFileShareStorage 键值来控制 FS 的使用。若要开启 FS，请根据如下所示更改该值：
<Add Key="WebServiceUseFileShareStorage" Value="true" />
若要关闭 FS，只需将该键值设置回“false”。
注意：默认情况下，FS 将快照数据保存到文件系统的 C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.instanceReporting ServicesRSTempFiles 目录下。CleanupCycleMinutes，位于 RSReportServer.config 文件中，控制未使用的 FS 数据的删除频率。对于操作频繁的系统，在设置该文件夹的存储空间需求时应十分谨慎，以免超出了可用的存储空间限制。
如 果 Report Server 使用本地目录而不是远程目录，那么它不会利用文件系统存储。快照数据已经保存在本地的 SQL Server 关系型数据库中，而该数据库则针对数据的存储和检索进行了充分优化。如果配置本地目录系统以使其使用文件系统存储，会造成存储空间和快照管理出现不必要的 冗余。
压缩和文件系统存储的影响
微软已经在 4 颗处理器的远程系统上测试了压缩和 FS 快照存储对性能的影响。两种技术都能提高系统在重负载情况下的处理能力。虽然压缩会加重处理器的负担，但它也降低了报告服务器和目录之间的网络流量。
表 5
| 每秒的平均请求数（与基准数据的比值） | 每小时的页面浏览量（与基准数据的比值） | 峰值会话数（与基准数据的比值） | |
|
未压缩 |
基准 |
基准 |
基准 |
|
SQL 压缩 |
基准 |
109% |
基准 |
|
文件系统存储 |
126% |
129% |
113% |
文件系统存储允许您支持更多数量的用户会话，同时不会增加系统的响应时间。显而易见，FS 设置具有最佳的伸缩性和处理能力。在测试 4 处理器的远程目录系统时，微软通过开启快照数据的文件系统存储，将能够支持的并发用户会话数量提高了 13%。
关键点
| • |
通过使用更多缓存实例和快照来代替实时报告，可以切实有效地提高现有系统的容量。 |
| • |
对于大容量报告环境，使用文件系统快照可为横向伸缩的远程服务器实现方式提供尽可能高的处理能力和尽可能快的响应速度。 |
性能优化最佳实践
本部分内容总结了容量规划和性能优化的指导原则和最佳实践。
选择一种配置
通过阅读纵向伸缩和横向伸缩指南，各种系统配置的报告能力各不相同这一点变得愈加清晰了。
最 基本的配置方式是使用本地目录的 2 处理器 Report Server。而最高端的配置是横向伸缩配置，它具有强大的伸缩能力和优异的性能表现。虽然本白皮书中的测试仅仅讨论了使用远程目录的四台配备 2 颗处理器的 Report Server 的横向伸缩配置，但是使用更大型的横向伸缩配置也很容易。
在这两种极端之间，您可以选择远程承载目录，向本地或远程实现方式添加处理器，或者以“Web 园”的方式将处理能力分配给单个系统中的多个处理器。
在为环境选择正确的配置方式时，首先需要确定您对性能的特定要求。以下是可以使用的一些简单指南：
| • |
如果您的系统可以容纳更多内存，请添加这些内存。这是因为内存占用是您可能遇到的第一个瓶颈。 |
| • |
如果您担心伸缩性并且运行一个本地目录系统，要做的第一件事情就是在单独的服务器上承载报告目录。只有将目录分隔出去才能通过增加处理器而显著提高性能和负载方面的伸缩性。 |
| • |
对于 4 颗处理器以下的系统，纵向伸缩和横向伸缩都是不错的方法。超过这个数字之后，横向伸缩可能是最安全和最灵活的伸缩途径。但是，我们并没有对大型的 SMP 系统进行测试。 |
横向伸缩配置方式中的横向伸缩让您能够避免某些过程——例如设计特别报告和预先计划的报告操作——干扰交互式报告的运行。例如：
| • |
拿出一台特定的 Report Server 作为所有 Report Builder 请求的前端，使用其余 Report Servers 处理交互式报告。 |
| • |
拿出一台或多台 Report Servers 用于定期订阅或由事件驱动的报告生成工作。 |
通用性能优化技巧
因 为 Report Server 目录承载在 SQL Server 上，如果怀疑数据库存在性能问题，可以应用针对 SQL Server 数据库服务器的性能优化而提出的建议。这可能涉及从中获取构建报告所需数据的源数据库，也可能涉及用于支持所有报告服务实现的目录数据库。可以通过以下地 址找到有关 SQL Server 优化的详细信息：http://www.microsoft.com/technet/ ，SQL Server 联机图书的“数据层：一条数据库优化途径”和 的“性能评估”章节也提供了相关优化信息。
以下是一些通用的性能优化技巧，在优化 Reporting Services 时请务必谨记在心：
| • |
优 化您的报告查询。通常，大部分报告执行时间都用来执行查询和取得结果。如果您正在使用 SQL Server，诸如 Query Analyzer 和 Profiler 这样的工具可帮助您优化查询。此外，Database Tuning Advisor 也可为数据库建议更好的索引方式。您还应该考虑使用 Analysis Services 提高性能。 |
| • |
如果您在报告中不需要某些数据，请不要取得这些数据。使用数据库操作（如筛选、分组和汇集）可减少报告处理的数据量并因此提高性能。 |
| • |
让报告的大小和复杂性保持适度。很少有用户真的希望查看 1000 页的报告。如果您发现需要处理大型报告，请想办法将它们分解为较小的数据块。 |
| • |
如 果在单用户的情况下性能也很糟糕，请检查 ASP.NET 类别下的 Application Restarts 计数器。已知某些防病毒软件会“修改”配置文件，并因此导致 Application Domain 在 Report Server Web 服务中频繁重新启动。有关更多信息，请在 http://support.microsoft.com/ 上搜索有关防病毒和 ASP.NET 的文章。 |
| • |
如果在停止活动一段时间后首次访问 Web 服务时性能缓慢，请在 IIS Manager 的 Application 的 Performance 选项卡上禁用空闲时间超时。 |
| • |
尽可能使用缓存/快照数据执行报告（与实时数据相比而言）。 |
| • |
将不重要的后台处理限制到非高峰时间段执行，以避免与在线用户争夺资源。 |
| • |
如果您的报告服务器拥有 4GB 内存，请记住在 C:boot.ini 中设置 /3GB 开关，以便应用程序能够使用这些内存。 |
| • |
如果在用户使用系统时执行诸如清理 Reporting Services 中的会话这样的维护管理工作，代价将十分昂贵。有关如何调整 RSReportServer.config 中的 CleanupCycleMinutes 时间间隔的说明，请参见附录 A. |
| • |
在多个数据文件上创建 Report Server 目录。可以将数据和日志放在不同的物理磁盘上来实现这个目的。具体做法请参见附录 A. |
使用 Web 园
在 Microsoft® Windows® 2003 Server 上，可以通过配置“最大工作进程数”(Maximum Number of Worker Processes） 设置来提高伸缩性。
为 了找到该 Internet 信息服务 (IIS) 设置，请打开 IIS Manager 工具并查看分配给每个 Reporting Services 虚拟目录 (vdir) 的应用程序池的属性。默认情况下，这些属性名为 Reports 和 ReportServer。您首先必须通过右击 vdir 并选择属性选项来确定分配给每个 vdir 的应用程序池。分配的应用程序池将出现在“虚拟目录”选项卡的底部。
在确定了正在使用的应用程序池之后，下一步便是打开所分配应用程序池的 属性。也可以通过 IIS Manager 访问该属性。接着，找到“最大工作进程数”设置。通过右击分配的应用程序池，选择属性选项并查看“性能”选项卡，可找到该设置。“最大工作进程数”设置出 现在“性能”选项卡的底部。
在配备 2 颗处理器和 4 颗处理器的系统上，提高工作进程的最大数量对系统容量和稳定性具有积极的影响。具体来说，在配备 4 颗处理器的系统上，将工作进程的最大数目从 1 更改为 4 可使 Report Processor 在性能出现下降之前处理更多的并发会话负载。更改该设置对配备 2 颗处理器的远程系统的影响小于配备 4 颗处理器的远程系统。
如果您的 Reporting Services 所运行的系统配备的处理器数量多于 4 颗，32 位寻址能力可能无法提供足够的内存供多于 4 颗的处理器使用。您应执行更多测试来确认这些结果。
其他工作负载的优化
虽然本白皮书主要关注交互式工作负载，但以下部分也提供了有关预定报告和特别报告负载的提示和技巧。未来版本的白皮书也将提供针对这些应用情境的附加指南。
预定报告的交付性能
预 定报告或订阅报告按照预先计划的时间运行，因此接受您的控制。如果 Reporting Services 环境提供了预定报告和按需报告，可将订阅报告的处理工作隔离到一台单独的 Report Server 上。然后，可像其他 Report Server 一样访问同一个目录，但是它并不处理交互式请求。这样，订阅报告的处理工作不会对按需报告的处理过程造成影响。
与交互式负载类似，预定操作的伸缩性也可以借助横向伸缩配置而得到提高。所有后台操作都放在目录数据库的一个队列中，与之连接的每台服务器都从中取出一个作业进行处理。
特别报告的性能
SQL Server 2005 Reporting Services 提供了一个特别报告工具，允许企业用户以交互方式创建他们自己的报告。Report Builder 包括一个业务查询模型，用户无需深入了解底层数据源即可构造出报告。
在使用 Report Builder 时存在一个风险，即企业用户在构造和运行复杂的资源密集型报告时会占用大量资源，这不仅会影响 Report Server，而且还会影响到源系统。
如果您希望广泛使用 Report Builder，可以采取某些步骤保护整体系统性能不受损害。例如：
| • |
将 Report Builder 会话隔离到一台专用的 Report Server 上，防止意料之外的负载对其他用户的交互式报告处理造成影响。 |
| • |
不 要让 Report Builder 会话直接与生产环境中的 OLTP 系统进行联系。相反，应将它们导向生产型数据源的副本。根据所需延迟时间的不同，可以使用数据库镜像和复制这样的技术来构建副本，或者使用 Integration Services 创建数据集市。通过这种方式，可避免不受控制的报告构建活动对生产系统产生负面影响。 |
运行您自己的性能测试
虽 然，模拟真实的负载条件不是一件轻松的工作，但我们强烈建议花时间这样做。许多系统在投入生产环境后遭遇到性能问题，其原因均在于没有在具体实施之前执行 足够的压力测试。正确的容量规划和足以支持生产负载的充足服务器是在系统投入实际运行前避免各种主要问题的最佳方法。至少，您的部署计划中应包括以下两项 工作：
| • |
模拟您的 Reporting Services 系统在投入生产环境后可能遇到的有代表性的负载。 |
| • |
在与计划中的生产环境基本相同的环境下执行测试。 |
通 过执行上述两项工作并记录在“分析指标”一节中讨论的指标，可以在规划部署时建立真实的性能基准。这样的基准在将来检验应用程序、配置或硬件的更改效果时 十分有用。当使用某个已建立的基准时，可以通过重新运行相同的测试来验证拟议的更改是否会对性能造成负面影响。在任何时候，只要对系统进行了大的更改，都 应重新建立性能基准。
微软及第三方厂商提供了众多压力测试工具，可使用它们建立性能基准。Microsoft® Visual Studio® 2005 Team Test Edition 包括了用于执行网站负载测试的工具。更多相关信息，请访问：http://msdn.microsoft.com/.
本白皮书的附录介绍了大量的性能计数器，帮助您顺利执行测试。
性能因素
在确定您的性能需求时，首先必须理解您对工作负载的需要。有些用户使用 Reporting Services 并通过企业门户提供按需报告，而有些用户则需要处理和提供预定报告。此外，有些用户还支持使用 Report Builder 创建特别报告。
影响工作负载和性能的其他因素包括：
| • |
同时提出报告请求的用户的数量 同时活动的会话数量越多，消耗的计算机资源也就越多。 |
| • |
报告定义的规模和复杂性 与处理行数很少的简单报告相比，处理包含大量行的报告显然需要更多资源。 |
| • |
是使用缓存或快照数据执行报告，还是使用实时数据执行报告。 使用缓存/快照数据执行的报告占用的资源显著少于使用实时数据的报告。此外，使用缓存报告可减少从中获取数据的源系统承担的负载 |
| • |
Reporting Services 从中获取报告数据的源数据系统的性能 如果针对这些系统执行查询时速度缓慢，则说明您的报告也将运行缓慢。 |
| • |
呈现报告时请求的格式 PDF 或 Microsoft® Excel® 这样的格式比 HTML 格式更加耗用资源。 |
| • |
承载目录的数据库服务器的性能 与源数据系统类似，如果承载目录的系统十分缓慢，那么报告的执行速度也将十分缓慢。 |
正在进行设计或需要由用户进行配置的许多事项也会影响报告的性能。这包括：
| • |
Reporting Services 配置文件、IIS 以及 Microsoft® Windows 操作系统中的应用程序设置。 |
| • |
支持报告应用程序的硬件配置和设计。 |
| • |
诸如交付基础结构这样的外部因素，包括网络容量、用于交付订阅的电子邮件服务器的性能或者是文件共享的可用性和性能。 |
若要正确规划任何 Reporting Services 部署的容量，首先需要理解您的工作负载具有的特性。您的工作负载可能随时间发生变化，并且在每月、每周或每日的使用中发生波动，具体情况则取决于各种业务因素的影响。
分析指标
当您确定系统的性能基准时，应该依据有意义的指标来进行确定。微软在其伸缩性测试中使用了如下指标：
| • |
Simultaneous Session（并发会话） |
| • |
Average Requests per Second（每秒的平均请求数） |
| • |
Median Response Time（中值响应时间） |
| • |
Total Page Views per Minute（每分钟的总页面浏览量） |
Simultaneous Session指标是确定其他指标的优秀变量。例如，可以从 100 个并发会话开始，并以每次后续运行增加 100 个的速度进行增长，以这种方式产生测试负载。
The Average Requests per Second?指标有助于您理解每个给定的系统配置能够成功支持多少个并发的 Web 请求。只要系统没有在特定负载下表现的难以为继，每次系统测试都应该为收到的所有请求提供同样的服务。
如 果以每秒的请求数相对于并发会话数绘制图形，可以找到曲线的顶点，该顶点代表了系统能够应付的“每秒平均请求数”的最大值。此图形可帮助您了解每个系统能 够支持的每秒请求数峰值和最大会话数。显然，如果希望了解“每分钟平均请求数”或“每小时平均请求数”，可以轻松地对“每秒平均请求数”进行外推。
“中值响应时间”（收到最后一个字节的时间，或者说 TTLB）是一个常见指标，用来了解 Reporting Services 需要花费多长的时间才能对报告请求做出响应。显然，响应时间越低越好
“每分钟的总页面浏览量”可帮助我们了解每种系统配置能够支持的报告执行数量以及后续的页面浏览量。实际上，可以获得有关页面浏览量的更详细信息。这些信息包括：
| • |
初始报告请求 为了获得此信息，可模拟发出初始请求以查看报告第一页的用户。初始请求通常比后续页面浏览请求要花费更长的时间。 |
| • |
后续页面浏览 为了获得此信息，可模拟请求查看报告的后续页面的用户。 |
| • |
总页面浏览量 这是所有初始报告请求 (Initial Report Request)的总和，再加上所有后续页面浏览量 (Subsequent Page Views），这是一个综合值，代表所执行页面浏览请求的整体数量。 |
思考时间
在实际工作中，用户在查看报告结果和提交查看其他页或运行其他报告的后续请求之间通常有一段等待时间。
微软在内部测试中选择了一个在 25 - 35 秒之间的随机思考时间。该思考时间应当是比较真实的，因为我们假定执行报告的典型用户在浏览后续页面之前都会花费一定的时间查看报告结果。
命名用户总数和并发活动会话
命名用户总数并不等同于主动向 Reporting Services 发出请求的并发会话的数量。在规划您自己的部署时，请注意以下几点：
| • |
命名用户总数代表了获得授权和具有访问 Report Server 的潜在能力的所有用户的总和。 |
| • |
命名用户总数中只有一部分代表给定时间内系统上以交互形式开展工作的并发会话。 |
| • |
因为存在思考时间，这其中只有一部分属于在给定时间同时向 Report Server 发出请求的并发活动会话。 |
总结
Microsoft SQL Server Reporting Services 的设计目标是：满足各种组织的需要，提供经济、灵活的报告能力，优化企业生产力。
Reporting Services 构建在 .NET 平台和 Windows Server 系统的基础之上，其伸缩性和可靠性足以支持要求苛刻的企业环境。它具有模块化的可扩展架构，以及开放的接口和 API，几乎能够集成到所有 IT 环境之中。通过这种方式，它有效地将人员与遍布企业各处的信息联系在一起。
大多数情况下，增加计算机资源都能够以近乎线性的方式提高 Reporting Services 部署的伸缩性。增加系统容量的第一个合乎逻辑的步骤是将 Report Server 目录分隔到远程服务器上。然后，必须决定是以纵向伸缩还是横向伸缩的方式来提高 Reporting Services 的处理能力。微软执行的测试表明，这两种方式都十分有效。因此，您的选择在很大程度取决于您的经济能力和喜好。
无论最终选择何种伸缩途径，建立您自己的自定义基准都十分重要。这样，您可以在更改配置后，监视系统的处理能力是有所提高还是有所下降。只有测试能够反映您的特定用户需求的工作负载，才能够确定所做更改对系统造成的影响是积极的还是消极的。
微软提供了几个工具（请参见本白皮书中的介绍），帮助您测试和监视 Reporting Services 的性能表现。通过使用本白皮书提供的指导原则，您应该已经可以成功地对 Reporting Services 部署进行简单的容量规划，并有效地监视其后续操作。
附录 A：系统配置设置
当配置 Report Server 系统时，应该查看以下设置和选项以优化性能。在创建基准性能量度时，它们尤其显得重要。
CleanupCycleMinutes
CleanupCycleMinutes 字段控制 Reporting Services 执行特定维护和管理任务（例如清理过期会话和孤立会话）的频率。在繁忙时段执行这些任务的开销可能非常之大。如果有可用的磁盘空间来在更长期限内存储会话 数据，可提高 CleanupCycleMinutes 的值以降低维护管理工作的执行频率。您肯定还希望增加时间，以免它在运行基准性能测试时运行。
CleanupCycleMinutes 字段位于 RSReportServer.config 文件中。默认情况下，该文件位于 C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.InstanceReporting ServicesReportServer。默认设置为 10.但是，微软在自己的伸缩性测试中将其更改为 1200,以避免这些进程在测试运行过程中启动。
MaxActiveReqForOneUser
默 认情况下，Reporting Services 会限制单个用户可以同时运行的未完成 URL 和 Web 服务请求的数量，以避免遭受拒绝服务 (DOS) 攻击。作为管理员，您可以提高此限制，让每位用户能够同时打开更多请求。当到达此设置的上限后，Report Server 自动丢弃来自该用户的后续请求。
此值也可以在 RSReportServer.config 文件中找到。默认设置为 20。但是，根据您的测试环境中不重复用户的数量，您可能必须增加该值。
当 SQL Server 与 Report Server 位于同一台计算机上时，设置内存配置的限额。
通 过让 SQL Server “钉住”特定数量的内存，可以规定由 SQL Server 和 Report Server 分别使用的内存数量。为此，请将内存的最大和最小数量设置为计算机的物理内存的一部分。例如，如果计算机配备了 3 GB 内存并且所有 Windows 应用程序都可以使用这些内存，可以让 SQL Server 仅使用 1 GB 内存，而让 Reporting Services 使用剩余的内存。
ReportServerTempDB 分区
对 于伸缩性测试，微软创建了一个经过分区的 ReportServerTempDB 数据库，该数据库包括 10 个不同的 1 GB 大小的文件以及 1 个 1 GB 大小的事务日志，以提高磁盘 I/O 操作的并行度。如果在工作负载中使用快照执行测试，ReportServer 数据库的分区也会大有益处。所有 11 个文件都分配到单个 RAID 0+1 存储设备上，以优化目录读写操作的性能。下面是一个 T-SQL 脚本示例，简单演示了如何实现上述目的。
use master drop database ReportServerTempDB go create database ReportServerTempDB ON PRIMARY ( NAME = ReportServerTempDB1, FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.InstancedataReportServerTempDB1.mdf', SIZE = 1GB, FILEGROWTH = 20), ( NAME = ReportServerTempDB2, FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQLdataReportServerTempDB2.ndf', SIZE = 1GB, FILEGROWTH = 20), .. . ( NAME = ReportServerTempDB10, FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQL MSSQL.InstancedataReportServerTempDB10.ndf', SIZE = 1GB, FILEGROWTH = 20) LOG ON ( NAME = ReportServerTempDBLog, FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQL MSSQL.InstancedataReportServerTempDB_Log.ldf', SIZE = 1GB, FILEGROWTH = 20) COLLATE Latin1_General_CI_AS_KS_WS go use ReportServerTempDB exec sp_addrole ' RSExecRole' go
附录 B：性能测量工具
本部分内容介绍可用于测量和监视 Reporting Services 性能的各种工具。
Windows 性能监视器工具
可 使用集成化性能工具监视用于监视 Reporting Services 的性能计数器。运行 Reporting Services 的所有 Microsoft® Windows® 操作系统都包括了该工具。监视 Reporting Services 系统的特定性能计数器让您能够：
| • |
估计支持预期负载所需的系统要求。 |
| • |
创建性能基准，以测量配置更改和应用程序升级造成的影响。 |
| • |
监视存在负载情况下的应用程序性能，无论是真实负载还是模拟负载。 |
| • |
验证硬件升级是否按照预期对性能产生了积极的影响。 |
| • |
验证系统配置更改是否按照预期对性能产生了积极的影响。 |
如果需要在一台计算机上监视多个 Report Server 实例，可以同时或单独监视这些实例。选择要包括的实例是计数器添加过程的一部分。有关使用 Windows 附带的性能工具的更多信息，请参见微软 Windows 产品文档。
若要访问性能工具
| • |
从“开始”菜单上选择“运行”。 |
| • |
在“打开”文本框中输入“perfmon”，然后单击“确定”。 |
| • |
在性能监视器工具中，在左侧窗格里选择 System Monitor 对象，然后右击“性能”图表。 |
| • |
选择“添加计数器”。 |
现在，可以开始选择这些对象和要监视的计数器了。
ASP.NET 应用程序性能计数器
有关 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 应用程序具有的特定性能问题时，下表中的性
