文件系统存储
对于快照存储的其他选项是使用文件系统存储。这样的设置并不影响SQL压缩设置，因为这些数据存储在文件系统中。
文件系统快照存储也适合远程目录和向外扩展的报表服务部署。当文件系统存储可用时，快照数据被存留到报表服务器的本地文件系统中。这使得报表服务器能够避免到目录上走弯路，以支持会话和报表请求。
你可以控制文件系统的使用，通过改变在RSReportServer 中的WebServiceUseFileShareStorage的值。在config file上，打开文件系统，改变值如下所示：
< Add Key="WebServiceUseFileShareStorage" Value="true" / >
将key的值改为“false”时，表示关掉文件系统。
注意，在默认情况下，文件系统存储快照数据到文件系统的目录：C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.instanceReporting ServicesRSTempFiles. CleanupCycleMinutes，位于RSReportServer内。config file控制如何频繁的无用文件系统数据应该被移除。应该注意系统文件夹的准确的存储需求，以避免超出存储极限。
如果报表服务器使用本地的目录来代替远程目录，那么使用文件存储就没有什么意义了。快照数据已经存储在SQL Server关系型数据库中，该数据库是高度优化来执行数据存储和重新检索的。利用文件系统存储来配置一个本地目录系统将引入非必要的存储冗余和快照管理。
压缩和文件系统存储的效果
微软在4-处理器远程系统上测试了压缩和文件系统快照存储的效果。两种技术在重负荷时都可以增加系统的能力。尽管压缩增加了处理器的工作量，但是它也能减少报表服务器和目录之间的通信量。
表 5
|
Avg Req / Sec % of baseline |
Page Views/Hr % of baseline |
Peak sessions attained % of baseline |
|
| No compression | Baseline | Baseline | Baseline |
| SQL compression | Baseline | 109% | Baseline |
| File System storage | 126% | 129% | 113% |
文件系统存储让你支持更多的用户会话数，而不用降低响应时间。很明显，文件系统设置提供了最好的扩展和能力。在测试一个4-处理器的远程目录系统中，当打开快照数据的文件系统时，能够支持多于13%的并发用户会话数量。
关键点
◆你可以增加现有系统的虚拟能力，通过使用更多的缓存实例和快照代替实况报表。
◆对于高数量的报表环境，利用文件系统快照在向外扩展和远程服务器实现中提供最高可能的能力水平和响应时间。
性能优化的最佳实践
本节主要概述了工作指南和最佳的能力计划和性能优化实践。
选择配置
回顾向上扩展和向外扩展指南，就报表能力而言有一个系统配置谱变得越来越清晰了。
在该谱的最低端是带有本地目录的2-处理器报表服务器。在最高端是向外扩展的报表服务器，它提供了可扩展的能力和性能。尽管本文的测试仅仅包含了向外扩展的配置，4个2-处理器的报表服务器和一个远程目录，向外扩展能够很容易地变大。
在这两种选择之间，你可以使目录位于远程，增加处理器到一个本地实现或者远程实现，同时在Web场方法的单个系统中进行拆分处理。
为了给你的工作环境选择恰当的配置，首先要求识别需要的特定性能需求。以下是一些简单的指导：
◆如果你的系统能够提供更多的内存，就添加一些。这是因为内存消耗是你第一个会遇到的瓶颈。
◆如果你考虑扩展性并运行在本地目录上，第一件需要做的事情是使目录分布到独立的服务器上。仅仅通过拆分目录，你可以获得明显的在性能方面的扩展性，通过增加处理器也可以提高负荷。
◆向上扩展和向外扩展都是一种好的方法对于达到4处理器的服务器。超过这个数，向外扩展可能是最安全和最可伸缩的方法。大的SMP系统还没有完成测试。
在向外扩展的配置的向外扩展让你能够保持一定的处理，如实时报表的设计和预订报表操作，而不受交互的妨碍。比如：
◆采用一个特定的报表服务器作为前端服务器来处理所有的报表创建请求，使其他的服务器有空处理交互式报表。
◆采用一个或者多个报表服务器来处理有序的订阅或者事件驱动报表的产生。
一般的性能优化技巧
由于报表服务器目录是由SQL Server来管理，如果你怀疑数据库性能问题，建议优化SQL Server数据库的性能。这可能包括用来创建报表的源数据库或者用来支持所有报表服务执行的目录数据库。你可以在http://www.microsoft.com/technet/找到优化SQL Server数据库的信息，在“The Data Tier: An Approach to Database Optimization”里；和在线的SQL Server书的性能评估章节里。
以下是一些常用的性能优化技术，使用报表服务时，当把它们记下。
◆优化你的报表查询。通常，大量的报表执行时间花费在执行查询和重新检索结果上。假如你使用SQL Server，像Query Analyzer 和 Profiler工具可以帮助你优化查询。同时，数据库Tuning Advisor能建议更好的数据库索引。你应该考虑通过使用分析服务来增加性能。
◆如果你不需要报表数据，请不要检索它。使用数据库操作，如过滤、分组和聚集可以减少大量的要求在报表中处理的数据，为此也可以改进性能。
◆使你的报表大小和复杂性适度。很少的用户真正希望看到1000页的报表。假如你需要处理一个大的报表，请寻找一些方法使它们变成小部分来进行处理。
◆如果性能非常差即使对于单个用户，检查ASP.NET类别中的应用程序重启计数器。一些防毒软件被认为“接触”配置文件，因此导致扩张的应用程序域在报表服务器Web服务上重启。更多信息，请查阅http://support.microsoft.com/上的关于抗病毒和ASP.NET的文章
◆假如在第一次Web服务访问时性能很慢，一段时期都没有反应，在IIS管理器中使在性能tab上的空闲time-out为无效。
◆如果可能的话，从缓存或者快照数据中执行报表，而不是实况数据。
◆在非峰值期间，限制非必要的后台处理，避免和在线用户竞争资源。
◆如果你的报表服务器有4GB内存，记得设置3GB 转换在C:oot.ini上，以便应用程序处理时能用到。
◆常规任务如清理报表服务中的会话将会变得非常耗资源，如果执行时用户正在系统上。关于如何在RSReportServer. config file 上调整CleanupCycleMinutes间隔的说明在附录A中进行讨论。
◆在少量的数据文件上创建报表服务器目录，通过把数据放到不同物理盘上的日志文件中。这些在附录A中将详述。
使用Web场
在Microsoft Windows 2003 Server版上，你可以通过设置最大的工作处理器数来进行扩展。为了定位IIS的设置，打开IIS管理工具，然后查看应用程序池的属性。默认时，这些命名为Reports and ReportServer。你必须首先决定是什么应用程序池被分配到每一个虚拟目录上，通过右键点击然后选择选项。被分配的应用程序池将出现在虚拟目录tab的底部。
当你知道那个应用程序池在用，下一步就是打开应用程序池的属性信息。这些信息可以通过IIS管理器来访问。下一步，定位最大的工作处理器数。通过右键点击然后选择选项，可以看到性能tab。设置的最大工作处理器数将出现在性能tab的底部。
在2-处理器和4-处理器系统上，增加工作处理器对能力和扩展有积极影响。
尤其，在4-处理器系统上将最大的工作处理器数由1变为4，将使报表处理器在性能开始下降之前能够处理更大的并发会话。在2-处理器远程实现上改变设置比在4-处理器远程实现上影响要小。如果你所使用的报表服务系统，有4个以上的处理器，32位地址可能不能够提供足够的内存。你应该进行额外的测试。
其他工作的优化
尽管本白皮书主要关注交互性的工作，以下提供一些关于预定和实时报表工作的技巧。其他的指导将会在以后的白皮书中出现。
预定报表交付性能
预定或者订阅的报表有这样的优点：它可以在你的控制范围内发生。如果你的报表服务环境同时提供预定和按需的报表，你可以用一台单独的报表服务器来处理报表订阅。你然后可以访问像其他报表服务器一样的目录，但是不要管理交互式的请求。用这种方法，按需报表处理不能从订阅报表转移。和交互式的工作一样，预定操作的扩展能够在向外扩展的配置上增加。所有的后台操作都在目录数据库中排队，每一个连接的服务器能够推出一个作业进行处理。
实时报表性能
SQL Server 2005报表服务提供了实时的报表工具，使商业用户可以交互式的创建报表。报表创建包括一个商业查询模型，它能帮助用户构建报表，而不需要考虑太多下面的数据源。
在用报表创建工具时，有一个风险，那就是商业用户在构建和运行复杂的、资源密集型报表时会消耗很多资源，这可能不仅会影响到报表服务器，而且可能会影响源系统。
如果你期待报表创建工具能广泛使用，你可以采取一些步骤来保护整个系统性能，比如：
◆将报表创建会话应用到一台服务器上，使那些不可预见的装载不会影响到其他用户的交互式报表处理。
◆不要让报表创建会话直接和OLTP系统一起工作，而是，直接和产品数据源的备份打交道。为了得到更好的性能潜力，你可以进行一些组织，比如数据库镜像和复制技术，或者通过集成服务来创建数据市场。通过这种方式，可以避免使未管理的报表创建影响到产品系统。
执行自己的性能测试
去模拟现实世界的工作条件也不是一件很繁琐的事情，花一些时间去做是非常有意义的，也是值得推荐的。许多部署出现了性能相关的问题，在实施之前没有进行充分的压力测试。go live。对能力和服务器大小进行恰当的计划，对支持产品工作量是非常必要的事情，可以避免大量令你头疼的事。
至少，下面两个任务应该是你部署计划的一部分：
◆模拟一个有代表的工作量，它可能是你实施报表服务需要经历的。
◆执行一些反环境的测试，这样的环境可能和你产品环境差不多。
通过执行这两个任务，记录一些上面讨论的分析标准，你将能够在未来的部署中建立一个现实的性能基线。这个基线非常有用，你将用它来验证将来的应用程序、配置和硬件的改变。通过使用建立的基线，你能够证实通过简单的再运行同样的测试，一些被提议的更改并不会对性能产生逆影响。任何时候你对系统做一些重要的改变时，你应该重新建立一个性能基线。
微软和第三方有许多压力测试工具，它们可以用来建立性能基线。Microsoft Visual Studio 2005团队测试版包含了Web站点的负荷测试。更多的信息，参考http://msdn.microsoft.com/。
性能变量
为了得到性能需求，你首先应该明白自己的工作需要。一些用户通过公共入口去使用报表服务，以交付按需报表；其他的依赖于预定报表处理和交付。一些通过报表创建工具来支持实时报表创建。
其他影响工作量和性能的因素有：
◆同时进行报表请求的用户数
越多的激活了的会话，越消耗机器资源。
◆报表定义的大小和复杂度
复杂的报表，由大量数据构成的报表明显要占用比简单报表更多的资源。
◆报表的产生是采用缓存或者快照数据，还是采用实况数据
采用缓存或者快照数据来产生报表比采用实况数据消耗更少的资源。另外，采用缓存报表减少了源系统的负荷。
◆源数据系统的性能，报表服务是从源数据系统获取数据的
如果查询在原数据系统上缓慢的，那么报表的执行也将是缓慢的。
◆显示报表时的格式化请求
格式化像PDF或者Excel都比HTML要耗资源。
◆管理目录的数据库服务器性能
如源数据系统一样，如果管理目录的数据服务器性能太差，那么报表的显示也将更慢。
许多东西，由于设计的原因或者用户配置的原因都会影响到报表的性能。包括如下：
◆应用程序设置，如报表服务配置文件的配置，IIS和操作系统的配置。
◆支持报表应用程序的硬件配置和设计。
◆外部原因像交付基础设施，包括网络能力，为订阅交付的Email服务器的性能，甚至文件共享的有效性和性能。
为了更好的计划恰当的报表服务部署的能力，你首先必须明白你的工作量特征。由于商业因素，你的工作情况可能每月，每周或者每日的有波动。
分析标准
当你为你的系统确定性能基线时，你应该确定一些有意义的标准。微软常采用以下标准：
◆同步会话
◆每秒的平均请求数
◆响应时间中值
◆每分钟查看的总页数
同步会话的标准是一个用来确定其他标准的好的变量。比如，你开始的时候有100个同步会话，然后以每次100个递增来产生一个测试工作负荷。
每秒种的平均请求标准帮助你明白在假定的配置条件下，有多少Web请求可以同时进行。只要系统不是在做特定的服务，那么每个系统测试都应该能够等同的为所有请求服务。当你把每秒的请求数和同步的会话绘成图时，看看图形的顶点，它是每秒平均请求的最大值。它体现了系统能够服务时，每秒请求的峰值和会话的最大值。很明显，根据每分钟的请求数或者每小时的请求数，每秒的平均请求能够很容易被推断出。中值响应时间是一个普通的标准，可以用来理解报表服务需要多少时间来响应请求。很明显，时间越短越好。
根据每分钟查看的页面数，可以看出系统配置的能力，能够执行的报表数和并发的页面查看。你也可以得到更多的关于页面查看的细节信息，包括以下信息：
◆初始化报表请求
为了获得这些信息，模拟一个用户发出一个初始化请求，查看报表的第一页。初始化报表请求需要花费比并发页面查看请求更多的时间来处理。
◆并发的页面查看
为了获得这些信息，模拟一个用户发出请求去查看一个报表的并发页面。
◆总的页面查看
这是所有初始化报表请求，加上所有的并发页面查看的总和，提供了一个汇总的值，这个值体现了所有请求查看的页面总数。
思考时间
在现实生活中，在我们发出并发请求去查看其他页面或者运行其他报表之前，当我们查看报表结果时，通常需要等待。
在内部测试，微软选择了一个随机的思虑时间在25到35秒之间。这个思考时间看起来比较现实，假设用户执行一个报表，在访问并发页面之前花费了一定的时间来查看报表结果。
命名的用户数vs 同步激活的会话
一个命名的用户数不等于同步激活的会话数。当计划自己的部署时，记住如下信息：
◆命名的用户数表示了那些有权限和潜力来访问报表服务的人数。
◆在任意时刻，仅仅一少部分的命名用户会导致同步激活的会话。
◆由于思考时间，在任意时刻，仅仅一少部分的同步激活的会话会发出并发请求。
总结
Microsoft SQL Server报表服务是用来满足广大组织低本高效的需要，弹性报表是用来优化企业生产率。在.NET平台和Windows Server系统之上，报表服务提供了可扩展性和可靠性，用来满足企业环境。它的标准的可扩展体系结构，由开放接口和APIs组成，支持集成到几乎所有的IT环境。通过这种方法，它有效地使用户和他们在企业中所需的信息联系起来。
在大多数情形中，添加机器资源能够使报表服务部署的性能按线性增长。增加系统性能的第一个逻辑步骤是拆分报表服务目录到远程服务器上。随后，你必须决定是采用向上扩展还是采用向外扩展来追求更好的报表服务性能。微软测试证明两种方式都是有效的。因此，你的选择更多的取决于你自己的经济状况，自己希望的舒适程度和自己喜好。
忽略你最后选择的扩展方法，建立你自己的客户基线非常重要。这样你就可以监控到在你改变配置时，系统地性能是提高了还是降低了。
只有通过测量工作量才能反应用户需求，你才能决定更改是对系统有积极作用还是有消极作用。
微软提供了一些工具，如在白皮书中描述的一样，用来帮助你测量和监控报表服务的性能。使用文章中提供的指导，你应该能够为你的报表服务部署成功地执行基本性能计划，同时监控正在进行的操作。
附录A: 系统配置的设置
当配置你的报表服务系统，你应该看看以下的设置和选项，以优化你的系统性能。当创建基线性能测量时，它们是非常重要的。
CleanupCycleMinutes
CleanupCycleMinutes域控制多长的时间Reporting Services执行特定的常规事务，如清除超期或者失去联系的会话。这些工作在繁忙的时间内进行是比较耗资源的。
如果你有可用的磁盘空间用来长时间的存储会话数据，CleanupCycleMinutes值的增加减少了常规事务执行的时间。
CleanupCycleMinutes域驻留在RSReportServer. config file上。默认时，该文件位于C:Program FilesMicrosoft SQL ServerMSSQLMSSQL.InstanceReporting ServicesReportServer上。默认的设置值是10。而且，为了测试它的扩展性微软已经把值变到了1200，目的是在测试运行期间进行这些处理。
MaxActiveReqForOneUser
默认时，报表服务限制了明显的URL和Web服务请求数量，目的是为了避免DOS(denial of service)的攻击。作为一个管理人员，你可以增加这些限制，以便更多的请求可以为每一个用户同步打开。当到达上限时，报表服务器自动放弃那个用户随后的请求。这个值也可以在RSReportServer.config file中找到，默认的值为20。你也可以向上调，取决于在测试中有多少唯一用户。
当使用同样的机器作为报表服务器时，在SQL Server上设置内存配置限制
你可以把被SQL Server消耗的内存，和由Report Serve通过 “pinning” SQL Server而消耗的内存，划分到特定的内存数。这样做，设置最大和最小的内存数量到机器物理内存的一部分。
比如，在一个有3GB内存可用的机器上，你可以给SQL Server1GB，剩下的留给Reporting Services
ReportServerTempDB 分区
对于扩展性测试，微软创建了一个分区的ReportServerTempDB数据库，由10个独立的1GB文件和一个1GB交易日志组成，目的是为磁盘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：性能测试工具
该节描述了许多工具用来测试和监控报表服务性能。
Windows 性能监控工具
控制报表服务的性能统计类能够通过集成性能工具来控制。该工具是Microsoft Windows操作系统的一部分。报表服务执行中的监控特定的性能统计类，使你可以进行如下工作：
◆估计支持期望工作量的系统需求。
◆创建性能基线来测量配置更改和应用程序升级所带来的影响。
◆在负荷下监控应用程序性能，看看是真的还是假的增长了。
◆核实升级硬件是否带来了你所期望的性能影响。
◆检验系统配置更改是否带来了你所期望的性能影响。
如果你需要从单个机器上来监控多个报表服务实例，你可以一起或者单独的监控这些实例。选择包含那个实例是添加统计的一部分。对包含在Windows中的关于使用性能工具的信息，可以查看Windows产品文档。
访问性能工具
2．从开始菜单点击“Run”。
3．在打开的文本框中输入perfmon ，然后点击OK。
4．在性能工具中，在左边的长方块中选择系统监控对象，然后在性能图上右点击。
5．选择Add统计类。
你应该现在就开始进行以上工作。