SQL Server 2005可伸缩性和性能的计划（1）

核心提示：本白皮书提供了关于不同报表服务实现架构中可伸缩性的相关内容，也提供了一些基于使用Microsoft SQL Server Reporting Services完成您自己的性能测试的指导方针、建议和提示，SQL Server 2005可伸缩性和性能的计划（1），简介Microsoft® SQL Server&tr

本白皮书提供了关于不同报表服务实现架构中可伸缩性的相关内容。也提供了一些基于使用Microsoft SQL Server Reporting Services完成您自己的性能测试的指导方针、建议和提示。

简介

Microsoft® SQL Server™ Reporting Services是一个报表平台，包括可扩展和可管理的中央管理报表服务器和可扩展的基于Web、桌面的报表交付。报表服务是微软综合商业智能平台的重要组成部分。对于许多组织，通过报表来交付信息是一个非常重要的日常商务环节。因此，报表性能必须是一致的、可预见的。随着报表数据的增加，组织必须能够增加报表能力，以一种可预见的、成本低廉的方式。

关于该文档

该文档主要用来帮助客户和合作伙伴，在数据量增加的情况下，如何最好的计划、优化和扩展他们的报表服务执行。以下是本文的主要内容：

◆不同硬件配置的性能和扩展性，如scaling out 和scaling in

◆报表缓存和文件系统存储对性能的影响

◆优化报表服务的最佳实践

◆进行性能测试的建议

尽管该文章是写Microsoft SQL Server 2005 Reporting Services，但是大多数的信息对于早期的版本也同样适用。

先决条件

该白皮文档并不打算祥细的讲述报表服务。对于一些细节的信息，可以到http://www.microsoft.com/sql/reporting/网站上查阅。除了报表服务之外，该文档假设读者对以下内容已经熟悉：

◆Microsoft SQL Server

◆Internet Information Services (IIS)

◆Microsoft .NET 框架

这些信息在MSDN站点上可以查阅http://msdn.microsoft.com。

概述

Reporting Services是一个综合服务平台的Web的报表，用于创建、管理和交付传统的纸张报表，同时具有交互性，。当执行报表时，Reporting Services平台执行如下步骤：

◆重新得到报表数据

◆根据报表指示和报表定义来处理数据

◆用特定的格式来显示报表

Reporting Services也执行其他的任务来支持报表处理，如管理和处理订阅，管理和处理快照和缓存请求，和服务报表管理请求。

Reporting Services中的工作主要有三部分：

◆用户可以在线交互式的访问已发布的报表

◆通过订阅将预订的和事务驱动的报表以Email或者文件共享的形式交付给用户

◆通过在线用户实时地创建和自动的执行报表

本文的重点在第一部分，用户可以在线交互式的访问已发布的报表。该功能对于大多数用户来说是非常感兴趣的。订阅交付有可预订的优点，用户可以随时随地的进行控制。交互式报表更难进行计划，因为大多数依赖于报表的大小和复杂度，并发用户的多少和报表显示的格式。用户在应用交互式报表时，对系统响应速度也有较高的期待。

伴随着SQL Server 2005 Reporting Services的出现，终端用户可以通过新的报表生成器工具交互式的创建和执行报表。实时报表创建的额外负荷难于进行量化，因为这取决于用户想做什么和如何有效地做，实时报表的量化将在下一版本文件中进行讲述。本文主要包括一般的性能指导说明，创建交互式报表的负荷和在不同配置上进行测试。同时，最后的性能数据也取决于你自己的工作环境，你需要自行进行性能测试。本文中的图片和结果主要为了说明在不同配置上可能出现的扩展特征。

可扩展性vs可靠性

系统的可扩展性是很难定义的，因为对于不同的人有着不同的度量标准。容易引起混乱的是可扩展性和可靠性，它们常出现在同一文章中。可靠性对于任何的系统配置都是一个重要的考虑因素，它的存在或多或少的影响到了可扩展性。在本文中，可扩展性定义为：一种系统能力，能够在不改变系统的基本设计和构架的基础上支持系统工作量的增加。理想地，假如增加了系统资源，你应该增加相同比例的系统能力来处理更多的工作量。

这可能有点太直觉了，达到“准线形”的扩展性是非常困难的。在实际中，系统所需的能力并不能很好的满足线形增长。这是因为管理、协作和通信成本的超额也会在不同系统部件之间发生。系统可靠性是基于细微的不同看法。系统的可靠性是指“能够顺利地处理工作量增加，没有出现任何失败”。另外，当系统增加工作量时，可靠的系统应该能够不间断或者不同时停止工作。性能的退化也应该是一个平滑的过程。虽然，在压力过大时，任何系统都可能变得无效，但是对于可靠的系统却能够从这些事故中进行恢复。对报表服务进行成功的能力计划重点是找到工作负荷和系统能够平滑处理的工作量，创建可靠的系统来满足扩展需求。

向上扩展 vs 向外扩展

Reporting Services的可扩展性设计使用户可以按照自己的意愿在单个服务器或者多个服务器上部署部件。用户开始用Reporting Services时经常问到“是买一个大服务器(scale-up)还是买一个小的服务器(scale-out)”。本文将描述这些可扩展性特性，来帮助你解决这个问题。

一种向上扩展(scale-up)的方法是“利用大的、均匀的、多处理器的服务器来提供额外的能力”。这种方法的优点是“相对于scale-out，它可以提供一种简单的配置和管理过程”。scale-up同时也是SQL Serve关系引擎和分析服务的扩展方法。

向外扩展(Scale-out)，是企业版Reporting Services的一种配置，大多数用户都喜欢用这种方法。重要的是，Scale-out能完成如下工作：

◆使用户可以根据需要增加或者移除能力

◆提供一种可接受的、可管理的、可扩展的方式来增加和移除能力

◆允许繁重的工作量在许多日用服务器上进行平衡

◆提供了一种内部错误的容许度

如果你想采用scale-out配置来部署Reporting Services，注意多报表服务器之间的协作，使每个访问单个报表服务器的目录安装在一个本地或远程的SQL Server关系数据库。对于细节的信息请查看http://www.microsoft.com/sql/reporting/ 和http://technet.microsoft.com/sql.

报表服务组件

为了更好的理解可扩展性，我们首先来了解一下报表服务的体系结构，如下图1所示，还有各种组件。

图1：报表服务体系结构

报表服务可以分解为逻辑上的三层，如下表1所示：

表 1

组件	功能
报表服务器	一个Web服务，做如下事情：·　　　　处理SOAP 和URL 请求·　　　　处理报表，包括执行查询，检查表达式，产生输出格式·　　　　提供快照和报表缓存管理·　　　　支持并加强安全策略和权威性报表服务器同时提供Windows服务，可以负责预订和批处理操作，本文对此不作细述。
报表服务器 目录	以下两种SQL Server数据库构成目录：·　　　　ReportServer包含报表内容信息，有报表定义、报表元数据、数据源定义、快照和历史数据。它存储了安全设置，账户信息，预订信息和交付设置。·　　　　ReportServerTempDB里面包含的内容必须支持会话管理和报表的缓存数据。这些目录能够驻留在同一物理系统如报表服务器，或者单个的系统上（远程目录）。
客户应用程序	客户应用程序通过SOAP Web服务和URL请求来访问服务器。报表管理工具和报表查看器应用程序是客户应用程序，它们被包含在报表服务中。Microsoft® Visual Studio® 2005提供了报表查看器(Report Viewer)，用来控制嵌入在客户端的报表。报表创建工具(Report Builder)是实时报表创建的权威工具。许多第三方软件卖主也提供了他们自己的客户端应用程序。

扩展规范

本节描述了报表服务的基本配置选项，它们如何影响性能和扩展性。本节目的是帮助用户学习一种有效的报表服务配置和负荷需求，并回答如下问题：

◆你是否需要考虑把目录部署到远程服务器上？

◆向上扩展报表服务器和增加额外的报表服务器那个更好？

◆对于你的4-处理器报表服务器，什么配置是最好的？

虽然微软在不同的配置上所进行的测试导致了特定的报表工作量，实际的性能需求将依赖于你工作环境中的许多因素。包括如下因素：

◆并发用户的数量

◆报表产生的大小和复杂度

◆按需报表和订阅报表的产生

◆实况和缓存报表的产生

以下章节的测试结果被用来决定各种不同配置的相对性能和可扩展性特征。注意一些原始的规则如每秒查看的页数，在不同的环境中将有所不同。主要关注像在环境中对资源进行分布处理或者添加资源所带来的相对改进。后一章节提供了创建自己性能基线的指导。

本地vs远程配置

微软已经测试了两个本地配置，运行报表服务器和它的在单一的服务器上的目录。

图2：本地目录实施

在本地配置中，SQL Server关系型数据库将和报表服务竞争有效的机器资源。如果你有充足的资源，那就没有什么问题了。

你可能考虑设置最大的内存和最多数量的处理器供SQL Server数据库引擎使用，目的是为了减少和报表服务的竞争，更多的信息请看附录A。客户也选择如图2所示的配置，因为这仅仅需要SQL Server许可。

相反的，远程目录实现如图3所示，通过两个物理服务器（报表服务引擎和远程目录主机）来延伸报表服务组件。

图3：远程目录实现

远程配置消除了机器资源之间的竞争。然而，你必须在报表服务器和目录服务器之间提供充足的网络宽带

向上扩展和向外扩展

在你拆分目录到其他的系统之后，你可以选择通过增加处理器来向上扩展报表服务器，或者通过增加机器来向外扩展。图4描述了一种采用多报表服务器来访问单个目录的向外扩展配置。

图4：采用多报表服务器来访问单个目录的向外扩展配置

向外扩展的配置典型的是利用一个从任何报表服务器节点分离出来的远程关系型数据库服务器来管理目录。它不可能将目录存储在任何一个报表服务器节点，这种配置是不值得推荐的，因为数据库服务器将消耗报表服务器的资源。

一个4-处理器，向外扩展的配置使用2-处理器报表服务器访问一个远程目录。一个8-处理器，向外扩展的配置使用4个2-处理器报表服务器。因此，向外扩展的配置增加的不仅仅是处理器，还有内存和网络互联。

本地和远程目录性能比较

在可扩展性计划中，第一个想法就是考虑报表服务器目录是采用本地的还是远程的模式。

在本地模式中，同一个物理机器管理了报表服务器和报表服务器目录。目录独立于报表数据的源数据库，报表数据一般驻留在不同的服务器上。

单机配置是最简单的实现，也是最经济的方式，但是有少许缺点。最重要的是，移动目录到远程服务器是使用向外扩展配置的第一步。在随后的章节中将进行讨论。

为了回答采用增加处理器到本地的方式和拆分目录方式那种方式更好，将采用如下的系统配置来进行测试：

◆2-处理器报表服务器，本地目录（2-proc local）

◆2处理器报表服务器，远程目录(2-proc remote)

◆4-处理器报表服务器，本地目录(2-proc local)

◆4-处理器报表服务器，远程目录(4-proc remote)

这些测试结果显示了一些比较有意义的事实。

◆利用2-处理器系统，对于少许的负荷，本地和远程的执行结果大致相似。

◆4-处理器本地系统比2-处理器本地系统在每秒的请求中呈现较好性能；但也不是4-处理器远程系统性能的两倍。

表2显示了四种配置在峰值能力时的比较结果，峰值能力是性能开始下降到高于30秒极限的会话最大数量。

表2

	Avg Req / Sec	Peak sessions attained
2 Proc (Local)	Baseline	Baseline
2 Proc (Remote)	-10%	Baseline
4 Proc (Local)	53%	17%
4 Proc (Remote)	100%	117%

从2-处理器本地到2-处理器远程的实现，事实上对会话峰值没有什么影响。在吞吐量方面有细微的下降，因为数据在网络之间的转移。

在高工作量时，加倍本地目录实现的处理器(2-processor local 到 4-processor local)并不能实质性的加倍可用资源。它仅仅在到达峰值会话时提供了细微的增加和在每秒的请求时的53%的改进。

然而，在远程目录配置上，使处理器数由2变为4可以带来线性的增加。采用4处理器时，请求数量峰值比会话峰值加倍的多。

关键点

◆假如你运行一个2-处理器本地系统，拆分目录到其他的服务器将导致整个系统性能的细微改变。

◆拆分目录不能给管理和监控带来什么好处，因为系统不能在报表服务器和数据库处理之间分配资源。

◆假如你运行一个4-处理器的本地系统，拆分目录到其他服务器将出现明显的性能改善。

◆对于扩展，远程目录实现的第一步是采用向外扩展配置

向上扩展

本节主要关注通过在远程目录配置中增加处理器(scaling up)来增加可用的能力和性能。在这情形下，向上扩展的配置从2-处理器扩展到4-处理器。在随后的测试中，当响应时间超过了预定的极限时间30s时将达到极限，30s一般认为是用户难于容忍的响应时间。

表3

	Average requests / second	Maximum # Sessions	Page Views Per Minute
2 Proc (remote)	10.71 (Baseline)	600 (Baseline)	604 (Baseline)
4 Proc (remote)	23.91 (123%)	1300 (117%)	1327 (120%)

每秒的平均请求数

在大量用户使用时，一个4-处理器系统比2-处理器的远程系统能够处理明显更多的请求。加倍在远程目录中的可用处理器数目比加倍每台服务器平均请求有细微的增加。

会话的峰值

一个4-处理器远程配置能够支持比加倍一个2-处理器会话峰值更多的远程实现。

每分钟的页面查看

每分钟的页面查看数折射了所能提供的页面产生能力。当远程目录实现中的处理器由2个提高到4个时，你可以在高负荷时得到120%的页面查看性能改进。

关键点

◆在你拆分报表目录到独立系统之后，使处理器由2个增加到4个时本质上是加倍了报表服务的执行速度，而没有降低响应速度。

◆测试是在服务器上进行的，没有2个或4个处理器。大量处理器系统的优化在以后的测试中将进行检查。

向外扩展

本章节主要关注向外扩展配置的性能和能力情况。在微软的测试中，报表服务器事实上是在2-处理器远程目录实现中的复制品。因此，向外扩展的机器是2倍和4倍于所有的系统资源（内存、存储空间和网卡）还有处理器。

当你将2-处理器远程执行的系统能力与4-处理器和8-处理器向外扩展相比较时，通过向外扩展配置提供了接近线性的扩展。以下表格总结了2-处理器，4-处理器和8-处理器改进的百分比。

表4

	Peak page views/hr	Maximum simultaneous user session
2 Proc (remote)	10.71 (Baseline)	600 (Baseline)
2 X 2 Proc (remote)	23.87 (210%)	1300 (216%)
4 X 2 Proc (remote)	45.18 (378%)	2500 (416%)

比较每秒钟的平均请求峰值和所支持的会话峰值，2 X 2-处理器向外扩展配置提供了比2-处理器远程执行的线性值更好的结果。

从2 X 2-处理器向外扩展到 4 X 2-处理器向外扩展并没有提供真实的线性扩展。而且，它不能提供明显的能力改进，有89%的每秒请求改进和92%的所支持的会话峰值改进。

关键点

◆向外扩展的方式提供了更好的低本高效，在不需要大量硬件投资的情况下获得更好的能力

◆假如你期待继续增加报表服务需求，向外扩展是一种自行增加额外能力的弹性方式

比较向上扩展和向外扩展

一个直接的向上扩展和向外扩展的实例比较4-处理器远程目录和向外扩展的4-处理器。假设，4个处理器驻留在同一个报表服务器里，同时向外扩展利用2个2-处理器报表服务器。

测试结果显示在两种实现之间仅有少许差别。向外扩展在两个节点之间有8GB的内存，4-处理器远程有4GB的内存。考虑同等的会话数量，4-处理器系统的响应时间比较均匀。4-处理器向外扩展在响应时间上有细微的优势。期待将报表服务部署在ASP中。网络应用程序正好迎合了向外扩展配置中便宜硬件组装的优势。

关键点

如果你有2-处理器远程目录实现，需要使能力翻倍，你向上扩展到4-处理器报表服务器或者向外扩展到2个报表服务器都没有用。

尽管转移到向外扩展配置需要你转移到企业版的报表服务，除原始能力外它有许多优点。主要包括如下：

◆少量处理器的服务器比大型SMP服务器要便宜得多

◆额外的机器可以利用保留内存地址空间，而不用转移到64位的硬件上

◆用新服务器添加能力，而不是升级已存在的服务器，可以节省停工期

◆多样的报表服务器提供了更好的可用性，假如一个服务器失败了，其他的服务器能够继续接受请求

◆你可以轻松的向外扩展到6、8或者10处理器。SMP服务器一般在8处理器之后出现低性能回报

采用64位处理器

SQL Server 2005报表服务支持64位处理器，包括Intel Itanium2处理器，AMD 和Intel的x64体系结构处理器。在x64系统上，报表服务能够运行在原始的64位模式和32位WOW(Windows on Windows)子系统上。总的来说，64位系统运行在同一处理器上并不能提高报表的生产量。但是，主要的优点是用户可以查看和导出更大的报表。当处于高工作量时，你可能在64位机器上会得到更好的生产量，因为内存竞争会下降同时垃圾回收会更少发生。微软并不能够全面地测试这些平台，但会利用测试结果有计划的更新这些文档。

报表缓存和存储

在报表服务实现中，在性能和能力方面一个重要的因素是“实况地从原系统的数据中产生报表还是通过利用缓存或者快照数据”。本节描述了一些选项，和潜在的性能影响选项。

缓存实例

报表服务器拥有两层缓存：

1．当报表服务器产生报表时，它重新从报表服务器目录中得到报表定义，并从数据源中得到报表所需的数据。然后创建临时的报表格式（存储在会话缓存中），写到ReportServerTempDB数据库中。它利用这些结果，缓存实例来创建并汇成最后的报表。

对于每一个完全的“实况”报表，它都要重复这些步骤。它可以指导后续报表的请求，如果该报表已经处理完了并存在缓存中。这样就可以减少重新检索数据和创建报表的时间。

2．报表服务器也会尝试缓存输出格式，或者内存中的报表快照，或者文件系统中的临时目录。如果请求的结果在输出缓存中被找到，它将迂回于处理和描写步骤之间，因此将产生更好的性能。如果需要了解更多的关于如何决定使用何种缓存，可以参阅附录B中的性能统计类。

缓存最终将会过期，导致重新从报表服务器中获取新的数据。你可以根据预先确定的时间间隔来控制缓存期限，预定的（针对特定报表的或者共享的）或强制的期限。

缓存报表对存储有影响，虽然SQL Server 2005报表服务能简洁地存储数据同时也能够提供数据压缩。当决定应该保持多少缓存或者快照镜像时，应该考虑如下事情：

◆当缓存实例创建时，查询参数被应用。如果你需要一个报表带有不同的查询参数，报表服务将产生额外的缓存实例。

◆没有用于查询的报表参数，可以被用来从缓存实例中创建不同报表版本。

报表快照

快照涉及同样时间间隔报表格式，存储在一个更为持久的状态。比如，快照可以存储在报表服务器目录中，而不是存储在ReportServerTempDB中。目录也可以维持多时间间隔的版本，作为报表历史，允许用户在它们之间进行选择。

SQL Server 2005报表服务自动在目录中压缩快照。它也可以将快照镜像存储到本地文件系统。以下的章节将突出利用缓存实例所带来的性能影响，压缩快照，和文件系统存储。

缓存实例

一种可以改进报表服务部署的能力和规模的方式是避免执行依赖于实况数据的报表。你可以通过利用缓存数据来进行。

图5显示了重新检索、处理和描写一个有150K行数据的报表，用实况和缓存数据来执行。

图5：150-K 行单个报表的时间计算

当聚集时，这些数据说明了相比采用缓存，实况数据需要261%以上的时间来进行报表服务。那些需要返回大量实况数据的报表，比采用缓存数据方式的报表需要更加多的资源。

要求用户在系统使用峰值时避免运行实况报表是不合理的。通常，用户不能意识到运行这些报表会给系统性能和其他系统用户带来影响。一些“良民”实践使你会考虑传输到你的用户数来改进系统能力和响应，包括如下：

◆无论何时，避免使报表重新检索，执行大量的实况数据。用缓存数据来代替。

◆如果无法避免这种情形，至少尝试着限制这样的报表的运行数，尤其在高峰时间。

◆当可以从缓存数据中生成报表时，在非高峰时间内预定这些报表来更新缓存，以避免影响其他用户。

压缩快照存储

SQL Server 2005报表服务使管理人员可以自行决定快照数据存储在那里，如何存储。

使用快照能明显的改进报表性能，但是消耗了数据库存储空间。为了帮助平衡存储和性能问题，报表服务提供了压缩选项。默认的设置是压缩快照和报表定义。你也可以关闭压缩。

比如，在一个20千行的报表中，SQL快照压缩后减少了20%的压缩前大小。减少的部分不仅翻译到报表服务器目录中的重要存储，而且大大的减少了报表服务器和目录之间的通信量。