关于sql server：优化Sql Reporting Services 2005中巨量报表的PDF导出

Optimizing the PDF Export of Huge Reports in Sql Reporting Services 2005

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

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

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

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

网络服务调用我相信你们都见过：

1
2
3

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

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

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

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

从我尝试过的调整中，我很高兴地说任何超时问题都已消除。

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

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

有没有办法为 SSRS 打开响应分块？

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

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

我们缩小了从 SSRS 导出的大型 PDF 的范围，发现了 2 个罪魁祸首

1) 除非图像是 JPG 或 PNG 颜色类型 3，否则它们会扩展为 BMP\\'s See here

2) 除非您将 SSRS 配置为其他行为(不推荐)，否则 SSRS 会将字体或字体子集嵌入 PDF，除非它们是 5 种"标准"PDF 字体之一。

虽然大多数 Windows 操作系统开箱即用都没有安装任何标准字体(我猜是 Symbol 除外)，但我们发现，如果您使用 Times New Roman, Courier New, or Arial，那么正向和反向字体替换将需要地点。

转换 RDL 的最简单方法是将它们视为 XML 并搜索和替换 FontFamily 标记。

如果你必须使用非标准字体，那么，你仍然可以将伤害降到最低：

使用尽可能少的字体。搜索 RDL XML 以确保没有任何多余的字体。
如果您使用不同大小的字体，请使用 TTF 字体。
尽量不要混合字体的正常、粗体和斜体变体，否则会被多次嵌入。

Does anyone know of anyway to
reduce/optimize the PDF export phase
and or the size of the PDF without
lowering the total page count?

我有一些想法和问题：
1. 这是一份图形密集的报告吗？如果没有，您是否有以文本开头但被 SSRS PDF 渲染器转换为图形的表格(检查您是否可以选择 PDF 中的文本)？每页 41K 可能比应有的多，也可能不会，这取决于您的报告的信息密集程度。但是我们遇到过报告布局存在小问题的情况，例如表格渗入页面边缘，导致 SSRS PDF 渲染器"举手"并渲染表格作为图像而不是文本。显然，报告中的图形越少，文件越小。
2. 有没有一种方法可以轻松地将报告分解成碎片？例如，如果它是 10 个位置的报告，其中位置 1 后跟位置 2 等，在您的最终报告中，您是否可以独立于位置 2 部分运行位置 1 部分等？如果是这样，您可以在收到所有子报告后使用 PDFSharp 将 10 个子报告合并为一个最终 PDF。这给页码编号带来了一些困难，但没有什么不可克服的。