优化 Sql Reporting Services 2005 中海量报表的 PDF 导出

Question

首先，我明白运行超大/长时间运行的报告是一个可怕的想法。我知道 Microsoft 有一个经验法则，规定 SSRS 报告的执行时间不应超过 30 秒。然而，由于外部力量，例如遵守州法律，有时庞大的报告是首选的邪恶。

在我工作的地方，我们有一个从 Crystal Reports 迁移到 SSRS 的 asp.net (2.0) 应用程序。由于庞大的用户群和复杂的报告 UI 要求，我们有一组屏幕可以接受用户输入的参数并创建要在夜间运行的计划。由于应用程序支持多个报告框架，我们不使用 SSRS 的调度/快照功能。系统中的所有报告均由预定的控制台应用程序生成，该应用程序采用用户输入的参数，并使用创建报告时使用的相应报告解决方案生成报告。对于 SSRS 报告，控制台应用程序生成 SSRS 报告并通过 SSRS Web 服务 API 将它们导出为 PDF。

到目前为止，SSRS 比 Crystal 更容易处理，除了我们最近从 Crystal 报告转换为 SSRS 的某个 25,000 页的报告之外。SSRS 服务器是 64 位 2003 服务器，有 32 gigs 的运行 SSRS 2005 的内存。我们所有的小报告都工作得非常好，但是我们在处理像这个这样的大报告时遇到了麻烦。不幸的是，我们似乎无法通过 Web 服务 API 生成预测报告。生成/导出大约 30-35 分钟后会出现以下错误：

异常消息：基础连接已关闭：接收时发生意外错误。

Web 服务调用是我相信你们以前都见过的：

data = rs.Render(this.ReportPath, this.ExportFormat, null, deviceInfo,
   selectedParameters, null, null, out encoding, out mimeType, out usedParameters, 
   out warnings, out streamIds);

奇怪的是，如果使用报表管理器直接在报表服务器上运行报表，则该报表将运行/呈现/导出。为报告生成数据的过程运行大约 5 分钟。大约 12 分钟后，报告在浏览器/查看器中以 SSRS 本机格式呈现。通过报告管理器中的浏览器/查看器导出为 pdf 还需要 55 分钟。这工作可靠，并产生高达 1.03gb 的 pdf。

以下是我尝试通过 Web 服务 API 使报告工作的一些更明显的事情：

• 在报表服务器上将 HttpRuntime ExecutionTimeout 值设置为 3 小时
• 在报表服务器上禁用 http 保持活动状态
• 增加了报表服务器上的脚本超时
• 在服务器上将报告设置为永不超时
• 在客户端调用时将报告超时设置为几个小时

从我尝试过的调整来看，我很放心地说任何超时问题都已消除。

根据我对错误消息的研究，我相信默认情况下 Web 服务 API 不会发送分块响应。这意味着它尝试在一个响应中通过网络发送所有 1.3gb。在某一时刻，IIS 认输了。不幸的是，API 抽象了 Web 服务配置，所以我似乎找不到启用响应分块的方法。

1. 有没有人知道在不降低总页数的情况下减少/优化 PDF 导出阶段和/或 PDF 的大小？
2. 有没有办法为 SSRS 开启响应分块？
3. 关于为什么它在服务器上运行而不是通过 API 运行，还有其他人有任何其他理论吗？

编辑：阅读 kcrumley 的帖子后，我开始通过获取文件大小/页数来查看平均页面大小。有趣的是，在较小的报告中，数学计算得出，每页大约为 5K。有趣的是，当报告变大时，这个“平均值”会增加。例如，一份 8000 页的报告平均超过 40K/页。很奇怪。我还要补充一点，除了每个分组中的最后一页之外，每页的记录数是设置的，所以这不是某些页面比另一个页面有更多记录的情况。

Answer 1

1. 有谁知道如何在不降低总页数的情况下减少/优化 PDF 导出阶段和/或 PDF 的大小？

我有一些想法和问题：
1. 这是一份图形较多的报告吗？如果没有，您是否有最初为文本但由 SSRS PDF 渲染器转换为图形的表格（检查是否可以选择 PDF 中的文本）？每页 41K 可能会超出应有的范围，也可能不会，具体取决于您的报告的信息密度。但我们也遇到过报表布局出现小问题的情况，比如表格渗入页面边缘，导致 SSRS PDF 渲染器“举手投足”，并将表格渲染为图像而不是文本。显然，报告中的图形越少，文件大小就越小。
2. 有没有一种方法可以轻松地将报告分成几部分？例如，如果它是 10 个位置的报告，其中位置 1 后面跟着位置 2，等等，那么在您的最终报告中，您能否独立于位置 2 部分等运行位置 1 部分？如果是这样，您可以在收到全部10 份子报告后，使用PDFSharp将它们合并为一份最终 PDF。这会给页码编号带来一些困难，但并不是无法克服的。

3. 对于为什么它在服务器上运行而不是通过 API 运行，还有其他人有任何其他理论吗？

我的猜测是报告的庞大规模。我不记得什么是 IIS 设置以及什么是特定于 SSRS 的所有内容，但可能需要更新一些总体 IIS 设置（可能在 Metabase.xml 中）才能允许这么多数据通过。

您可以通过获取一份工作报告并使用 WAITFOR 在存储过程中构建较长的等待时间（假设您的 DBMS 使用 SQL Server）来隔离时间是否是问题。

本质上不是解决方案，而是想法。希望能帮助到你。