内容目录
简介
可扩展性vs可靠性
系统的可扩展性是很难定义的，因为对于不同的人有着不同的度量标准。容易引起混乱的是可扩展性和可靠性，它们常出现在同一文章中。可靠性对于任何的系统配置都是一个重要的考虑因素，它的存在或多或少的影响到了可扩展性。在本文中，可扩展性定义为：一种系统能力，能够在不改变系统的基本设计和构架的基础上支持系统工作量的增加。理想地，假如增加了系统资源，你应该增加相同比例的系统能力来处理更多的工作量。
这可能有点太直觉了，达到“准线形”的扩展性是非常困难的。在实际中，系统所需的能力并不能很好的满足线形增长。这是因为管理、协作和通信成本的超额也会在不同系统部件之间发生。系统可靠性是基于细微的不同看法。系统的可靠性是指“能够顺利地处理工作量增加，没有出现任何失败”。另外，当系统增加工作量时，可靠的系统应该能够不间断或者不同时停止工作。性能的退化也应该是一个平滑的过程。虽然，在压力过大时，任何系统都可能变得无效，但是对于可靠的系统却能够从这些事故中进行恢复。对报表服务进行成功的能力计划重点是找到工作负荷和系统能够平滑处理的工作量，创建可靠的系统来满足扩展需求。
向上扩展 vs 向外扩展
Reporting Services的可扩展性设计使用户可以按照自己的意愿在单个服务器或者多个服务器上部署部件。用户开始用Reporting Services时经常问到“是买一个大服务器(scale-up)还是买一个小的服务器(scale-out)”。本文将描述这些可扩展性特性，来帮助你解决这个问题。
一种向上扩展(scale-up)的方法是“利用大的、均匀的、多处理器的服务器来提供额外的能力”。这种方法的优点是“相对于scale-out，它可以提供一种简单的配置和管理过程”。scale-up同时也是SQL Serve关系引擎和分析服务的扩展方法。
向外扩展(Scale-out)，是企业版Reporting Services的一种配置，大多数用户都喜欢用这种方法。重要的是，Scale-out能完成如下工作：
◆使用户可以根据需要增加或者移除能力
扩展规范
本节描述了报表服务的基本配置选项，它们如何影响性能和扩展性。本节目的是帮助用户学习一种有效的报表服务配置和负荷需求，并回答如下问题：
◆你是否需要考虑把目录部署到远程服务器上？
本地和远程目录性能比较
在可扩展性计划中，第一个想法就是考虑报表服务器目录是采用本地的还是远程的模式。
在本地模式中，同一个物理机器管理了报表服务器和报表服务器目录。目录独立于报表数据的源数据库，报表数据一般驻留在不同的服务器上。
单机配置是最简单的实现，也是最经济的方式，但是有少许缺点。最重要的是，移动目录到远程服务器是使用向外扩展配置的第一步。在随后的章节中将进行讨论。
为了回答采用增加处理器到本地的方式和拆分目录方式那种方式更好，将采用如下的系统配置来进行测试：
◆2-处理器报表服务器，本地目录（2-proc local）
关键点
SQL Server 2005报表服务支持64位处理器，包括Intel Itanium2处理器，AMD 和Intel的x64体系结构处理器。在x64系统上，报表服务能够运行在原始的64位模式和32位WOW(Windows on Windows)子系统上。总的来说，64位系统运行在同一处理器上并不能提高报表的生产量。但是，主要的优点是用户可以查看和导出更大的报表。当处于高工作量时，你可能在64位机器上会得到更好的生产量，因为内存竞争会下降同时垃圾回收会更少发生。微软并不能够全面地测试这些平台，但会利用测试结果有计划的更新这些文档。 报表缓存和存储
压缩快照存储
一般的性能优化技巧
性能变量
附录A: 系统配置的设置
CleanupCycleMinutes域控制多长的时间Reporting Services执行特定的常规事务，如清除超期或者失去联系的会话。这些工作在繁忙的时间内进行是比较耗资源的。
默认时，报表服务限制了明显的URL和Web服务请求数量，目的是为了避免DOS(denial of service)的攻击。作为一个管理人员，你可以增加这些限制，以便更多的请求可以为每一个用户同步打开。当到达上限时，报表服务器自动放弃那个用户随后的请求。这个值也可以在RSReportServer.config file中找到，默认的值为20。你也可以向上调，取决于在测试中有多少唯一用户。
报表服务性能统计类
报表服务包括它自己的性能统计类和资源消耗。在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
◆处理请求的报表服务器实例的名字。
内容目录
简介
◆向外扩展的方式提供了更好的低本高效，在不需要大量硬件投资的情况下获得更好的能力
SQL Server 2005报表服务支持64位处理器，包括Intel Itanium2处理器，AMD 和Intel的x64体系结构处理器。在x64系统上，报表服务能够运行在原始的64位模式和32位WOW(Windows on Windows)子系统上。总的来说，64位系统运行在同一处理器上并不能提高报表的生产量。但是，主要的优点是用户可以查看和导出更大的报表。当处于高工作量时，你可能在64位机器上会得到更好的生产量，因为内存竞争会下降同时垃圾回收会更少发生。微软并不能够全面地测试这些平台，但会利用测试结果有计划的更新这些文档。 报表缓存和存储
CleanupCycleMinutes域控制多长的时间Reporting Services执行特定的常规事务，如清除超期或者失去联系的会话。这些工作在繁忙的时间内进行是比较耗资源的。
默认时，报表服务限制了明显的URL和Web服务请求数量，目的是为了避免DOS(denial of service)的攻击。作为一个管理人员，你可以增加这些限制，以便更多的请求可以为每一个用户同步打开。当到达上限时，报表服务器自动放弃那个用户随后的请求。这个值也可以在RSReportServer.config file中找到，默认的值为20。你也可以向上调，取决于在测试中有多少唯一用户。
◆处理请求的报表服务器实例的名字。