我想确定一个用于SQL Server Reporting Services的最佳设置，以用作SaaS基于Web的应用程序的集成报告工具。 所有的报告都是预定义的，用户可以select一个报告，并在基于Web的前端input一些参数。 然后将parameter passing给报表，该报表抽取数据，格式化结果，并将PDF或Excel文件返回给Web应用程序。
虽然我们有现有的SQL Server支持我们的Web应用程序，但没有安装Reporting Services。 选项包括：
1）将Reporting Services添加到现有的SQL Server实例
2）在已经运行SQL Server的物理服务器上创build一个新实例，并为Reporting Services使用该新的SQL实例
3）有一个单独的物理服务器的Reporting Services
虽然＃3是最佳的，它也花费额外的SQL Server许可证，这是不便宜的。 我不知道如果我select＃2获得多less，除了一些稳定。 选项＃1可能是阻力最小的path，但是我知道SSRS会带来一些相当大的开销，我不希望有太多的性能问题。
任何人都需要做这样的事情？ 轶事和意见的欢迎。
您没有指出SQL Server的版本。 请记住，SSRS 2005还需要在机器上安装IIS。 SSRS 2008没有。 它本身使用HTTP.SYS。 最佳的答案是＃3，但是，它确实取决于物理服务器上的现有负载以及要运行的报告的types。 ＃1 /＃2在性能方面基本上是相同的选项。
事实是，在不知道性能特点的情况下，这里没有人能告诉你最好的select。 你最好的办法就是先了解你的SQL服务器今天的performance，build立一个小型开发SSRS环境，并在testing报告的时候对其进行分析，然后做出决定。 如果您不确定从SQL Server获取性能configuration文件的起始位置，请允许我build议：
布伦特Ozar的性能调整的post
直到我们拥有一些专用的rs / as / mirroring服务器的免费许可证，我们才会走上第一条路线。 我限制了应用程序池的iis内存使用量。 有了这个合理的超时，我们希望减less对数据库引擎的影响。
我不会允许＃1系统上的任何adhoc（报告生成器）。
我真的会推＃3。 您也可以将其用于criticalcal数据库的数据库镜像或运行ssis。
我们上周在4天内提供了3600份报告 – 内存大约在300-1500MB之间。
我认为，相当大的开销是在旁观者的眼中。 例如，我pipe理的服务器之一是一个SQL Server 2000数据仓库，其中包含一个SQL Server 2005实例来存放Reporting Services。 我很less说SSRS对我们来说有相当大的开销，但这与我们如何使用SSRS有很大的关系。 我们正在将这两者整合到一个SQL Server 2008默认实例中，原因很多，主要是处理相对于数据仓库而言，SSRS对我们来说足够小的问题。 我们的报告less于50份，绝大多数报告正在计划之中。 我们也不做任何caching或快照。 所以，就我们而言，巩固绝对是一条路。
我们使用具有数据中心许可证和SQL CPU许可证的ESX虚拟服务器，所以我们没有与我们托pipe的SQL实例数量有关的问题，所以我的答案是…
将报告服务保存在单独的服务器上。 我们这样做的主要原因是SSRS往往是升级到“最新，最好”版本的服务，首先从SSRS和Visual Studio 2008的新function中获得最大收益。
我们的SSRS是SQL 2008 – 大多数数据库仍然是SQL2000 /和2005
如果您可以将数据保存在单独的服务器上，这也会有所帮助。 我们发现，同一系统上的数据库繁忙的SSRS服务器减慢了系统上其他用户的网页浏览速度。 当我们将数据移动到专门的“报告数据”服务器时，情况就不那么如此了。