Reporting Services 的伸缩性和性能表现规划(转载)

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

简介

Microsoft? SQL Server? Reporting Services 是一个将集中管理的报告服务器具有的伸缩性和易管理性与基于 Web 和桌面的报告交付手段集于一身的报告平台。Reporting Services 是微软功能全面的商业智能平台的重要组件。

对于许多组织，通过报告提供信息是日常业务操作的一种基本活动。所以，报告系统的性能表现必须确保一致和可预测。随着报告负载的增加，组织必须能够以一种可预期和具有成本效益的方式提高报告能力。

关于本文

本文旨在帮助客户和合作伙伴确定如何面对日益增加的负载，以最佳方式规划、优化和伸缩他们的报告服务实现架构。本白皮书讨论了以下主题：

虽然本白皮书关注的目标是 Microsoft SQL Server 2005 Reporting Services，但文中提供的大多数信息也适用于该产品的早期版本。

前提条件

本白皮书并不打算事无巨细地包含有关 Reporting Services 的所有信息。如需获得有关该产品的详细信息，请参见产品文档以及可通过以下地址获得的其他在线资源：http://www.microsoft.com/sql/reporting/.

除 Reporting Services 之外，本文档假设读者已经熟悉以下主题：

有关这些主题的信息可通过以下地址从 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

返回页首

伸缩指南

本部分内容介绍 Reporting Services 的基本配置选项，并描述它们对性能和伸缩性的影响。本部分内容的目标是帮助读者找出满足自身的性能和负载需要的有效 Reporting Services 配置，并且回答如下问题：

虽然微软对不同配置执行的测试均在施加特定报告负载的情况下得出了结果，但您的实际性能需求应视您的自身环境所特有的各项因素而定。这些因素包括：

后文中的测试结果仅用于确定各种不同配置的相对性能和伸缩特性。请注意，原始指标（例如每秒的页面浏览量）与您的环境和应用情境不同。我们的重点在于这些指标随着向环境分配或增添资源而取得的相对改善。本白皮书后面的章节为您创建自己的性能基准提供了操作指南。

本地配置和远程配置

微软测试了两种本地配置，在同一台服务器上运行 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 展示了四种配置方式的峰值处理能力（即性能保持在等于 30 秒的阀值之上时能够处理的最大会话数量）的比较结果。

表 2

从 2 处理器的本地实现方式切换到 2 处理器的远程实现方式本身对服务器能够支持的峰值会话数量不会产生实质性的影响。在吞吐量方面会有一点下降，因为通过网络传输数据会产生一定的开销。

在更高工作负载的情况下，成倍增加本地目录实现方式上的处理器数量（从 2 颗处理器的本地实现到 4 颗处理器的本地实现）实际并不能将可用资源提高两倍。它只能适度提高峰值会话数量，并在每秒处理的请求数方面有 53% 的改进。

但是，在远程目录实现方式中，成倍增加处理器（从 2 颗到 4 颗）可提供线性的伸缩能力。在 4 颗处理器的情况下，峰值请求数量的成倍增加还有甚于峰值会话数量的成倍增加。

关键点

纵向伸缩

本
部分内容讨论在远程目录配置方式中通过增加处理器数量（纵向伸缩）来提升系统的容量和性能。在本例中，纵向伸缩是从 2 颗处理器的远程系统切换为 4
颗处理器的远程系统。在以下测试中，当响应时间超过预先定义的 30 秒阀值之后便视为达到了极限，这个时间对于大多数用户来说似乎都是无法忍受的。

表 3

每秒的平均请求数

在高用户负载情况下，4 处理器系统每秒可以处理的请求数显然远远大于 2 颗处理器的远程系统。在远程目录实现方式中，成倍增加处理器的数量可以使得每秒的平均请求数稍稍高于原先的两倍。

最大会话数量

4 处理器的远程配置方式可以支持的最大会话数量超过了 2 颗处理器的远程实现方式所支持最大会话数量的 2 倍。

每分钟页面浏览量

每分钟页面浏览量这一指标考察了页面生成能力。在远程目录实现方式中，通过将处理器数量从 2 成倍增加到 4，可以在高负载情况下将页面浏览量提升为原先的 120%。

关键点

横向伸缩

本部分内容考察横向伸缩配置对容量和性能的影响。在微软进行的测试中，Report Servers 忠实地复制了 2 颗处理器远程目录实现方式中的服务器配置。因此，横向伸缩服务器的数量加倍，而所有系统资源（内存、存储和网卡）的数量则翻了四倍。

如果将 2 颗处理器的远程实现方式的系统处理能力与 4 颗或 8 颗处理器的横向伸缩配置进行对比，使用横向伸缩配置的系统可以提供近乎线性的伸缩能力。下表总结了 4 颗和 8 颗处理器的横向伸缩配置相对于作为基准的 2 颗处理器远程系统在各方面取得的进步。

表 4

比较每秒的峰值平均请求数以及支持的峰值会话数，2 X 2 处理器的横向伸缩配置方式提供了优于 2 颗处理器远程实现方式的线性伸缩能力。

如果仅比较各种横向伸缩实现，从 2 X 2 处理器的横向伸缩转移到 4 X 2 处理器的横向伸缩不会提供真正线性的伸缩能力。但是，它也可显著提升处理能力，每秒处理的请求数增加了 89%，而支持的峰值会话数则提高了 92%。

关键点

纵向伸缩和横向伸缩比较

纵向伸缩和横向伸缩应用方案的直接比较可以通过比较 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，但在获得能力提升之外还可获得其他众多益处。这些益处包括：

使用 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 有两级缓存：

缓存最终会过期，并因此导致 Report Server 收集新鲜的数据。可根据预定义的时间间隔、日程安排（特定于报告或共享）或强制过期来控制缓存过期时间。

缓存报告对存储区会产生影响，虽然 SQL Server 2005 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

文件系统存储允许您支持更多数量的用户会话，同时不会增加系统的响应时间。显而易见，FS 设置具有最佳的伸缩性和处理能力。在测试 4 处理器的远程目录系统时，微软通过开启快照数据的文件系统存储，将能够支持的并发用户会话数量提高了 13%。

关键点

返回页首

性能优化最佳实践

本部分内容总结了容量规划和性能优化的指导原则和最佳实践。

选择一种配置

通过阅读纵向伸缩和横向伸缩指南，各种系统配置的报告能力各不相同这一点变得愈加清晰了。

最 基本的配置方式是使用本地目录的 2 处理器 Report Server。而最高端的配置是横向伸缩配置，它具有强大的伸缩能力和优异的性能表现。虽然本白皮书中的测试仅仅讨论了使用远程目录的四台配备 2 颗处理器的 Report Server 的横向伸缩配置，但是使用更大型的横向伸缩配置也很容易。

在这两种极端之间，您可以选择远程承载目录，向本地或远程实现方式添加处理器，或者以“Web 园”的方式将处理能力分配给单个系统中的多个处理器。

在为环境选择正确的配置方式时，首先需要确定您对性能的特定要求。以下是可以使用的一些简单指南：

横向伸缩配置方式中的横向伸缩让您能够避免某些过程——例如设计特别报告和预先计划的报告操作——干扰交互式报告的运行。例如：

通用性能优化技巧

因 为 Report Server 目录承载在 SQL Server 上，如果怀疑数据库存在性能问题，可以应用针对 SQL Server 数据库服务器的性能优化而提出的建议。这可能涉及从中获取构建报告所需数据的源数据库，也可能涉及用于支持所有报告服务实现的目录数据库。可以通过以下地 址找到有关 SQL Server 优化的详细信息：http://www.microsoft.com/technet/ ，SQL Server 联机图书的“数据层：一条数据库优化途径”和 的“性能评估”章节也提供了相关优化信息。

以下是一些通用的性能优化技巧，在优化 Reporting Services 时请务必谨记在心：

使用 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，可以采取某些步骤保护整体系统性能不受损害。例如：

返回页首

运行您自己的性能测试

虽 然，模拟真实的负载条件不是一件轻松的工作，但我们强烈建议花时间这样做。许多系统在投入生产环境后遭遇到性能问题，其原因均在于没有在具体实施之前执行 足够的压力测试。正确的容量规划和足以支持生产负载的充足服务器是在系统投入实际运行前避免各种主要问题的最佳方法。至少，您的部署计划中应包括以下两项 工作：

通 过执行上述两项工作并记录在“分析指标”一节中讨论的指标，可以在规划部署时建立真实的性能基准。这样的基准在将来检验应用程序、配置或硬件的更改效果时 十分有用。当使用某个已建立的基准时，可以通过重新运行相同的测试来验证拟议的更改是否会对性能造成负面影响。在任何时候，只要对系统进行了大的更改，都 应重新建立性能基准。

微软及第三方厂商提供了众多压力测试工具，可使用它们建立性能基准。Microsoft® Visual Studio® 2005 Team Test Edition 包括了用于执行网站负载测试的工具。更多相关信息，请访问：http://msdn.microsoft.com/.
本白皮书的附录介绍了大量的性能计数器，帮助您顺利执行测试。

性能因素

在确定您的性能需求时，首先必须理解您对工作负载的需要。有些用户使用 Reporting Services 并通过企业门户提供按需报告，而有些用户则需要处理和提供预定报告。此外，有些用户还支持使用 Report Builder 创建特别报告。

影响工作负载和性能的其他因素包括：

正在进行设计或需要由用户进行配置的许多事项也会影响报告的性能。这包括：

若要正确规划任何 Reporting Services 部署的容量，首先需要理解您的工作负载具有的特性。您的工作负载可能随时间发生变化，并且在每月、每周或每日的使用中发生波动，具体情况则取决于各种业务因素的影响。

分析指标

当您确定系统的性能基准时，应该依据有意义的指标来进行确定。微软在其伸缩性测试中使用了如下指标：

Simultaneous Session指标是确定其他指标的优秀变量。例如，可以从 100 个并发会话开始，并以每次后续运行增加 100 个的速度进行增长，以这种方式产生测试负载。

The Average Requests per Second?指标有助于您理解每个给定的系统配置能够成功支持多少个并发的 Web 请求。只要系统没有在特定负载下表现的难以为继，每次系统测试都应该为收到的所有请求提供同样的服务。

如
果以每秒的请求数相对于并发会话数绘制图形，可以找到曲线的顶点，该顶点代表了系统能够应付的“每秒平均请求数”的最大值。此图形可帮助您了解每个系统能
够支持的每秒请求数峰值和最大会话数。显然，如果希望了解“每分钟平均请求数”或“每小时平均请求数”，可以轻松地对“每秒平均请求数”进行外推。

“中值响应时间”（收到最后一个字节的时间，或者说 TTLB）是一个常见指标，用来了解 Reporting Services 需要花费多长的时间才能对报告请求做出响应。显然，响应时间越低越好

“每分钟的总页面浏览量”可帮助我们了解每种系统配置能够支持的报告执行数量以及后续的页面浏览量。实际上，可以获得有关页面浏览量的更详细信息。这些信息包括：

思考时间

在实际工作中，用户在查看报告结果和提交查看其他页或运行其他报告的后续请求之间通常有一段等待时间。

微软在内部测试中选择了一个在 25 - 35 秒之间的随机思考时间。该思考时间应当是比较真实的，因为我们假定执行报告的典型用户在浏览后续页面之前都会花费一定的时间查看报告结果。

命名用户总数和并发活动会话

命名用户总数并不等同于主动向 Reporting Services 发出请求的并发会话的数量。在规划您自己的部署时，请注意以下几点：

返回页首

总结

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 产品文档。

若要访问性能工具

现在，可以开始选择这些对象和要监视的计数器了。

ASP.NET 应用程序性能计数器

有关 ASP.NET 应用程序性能计数器的大部分信息最近已被合并到一个题为“改善 .NET 应用程序的性能和伸缩性”的综合文档中。下表描述了一些可用于监视和优化 ASP.NET 应用程序（包括 Reporting Services）性能的重要计数器。

除了上表中介绍的这些核心监视要素之外，在您试图诊断 ASP.NET 应用程序具有的特定性能问题时，下表中的性