5

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

在我的工作地点，我们有一个 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 分钟后会出现以下错误：

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

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

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 服务配置，所以我似乎找不到启用响应分块的方法。

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

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

4

3 回答 3

4

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

1) 除非图像是 JPG 或 PNG 颜色类型 3，否则它们会扩展为 BMP 的请参见此处

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

尽管大多数 Windows 操作系统开箱即用都没有安装任何标准字体（我猜是 Symbol 除外），但我们发现如果您使用，Times New Roman, Courier New, or Arial则会发生正向和反向字体替换。

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

如果您必须使用非标准字体，那么，您仍然可以最大限度地减少损坏：

  • 使用尽可能少的字体。搜索 RDL XML 以确保没有任何多余的字体。
  • 如果您使用不同大小的字体，请使用 TTF 字体。
  • 尽量不要混合字体的正常、粗体和斜体变体，否则会被多次嵌入。
于 2012-05-07T12:05:22.123 回答
3
  1. 有谁知道在不降低总页数的情况下减少/优化 PDF 导出阶段和/或 PDF 的大小？

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

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

我的猜测是报告的大小。我不记得关于什么是 IIS 设置和什么是特定于 SSRS 的所有内容，但可能有一些整体 IIS 设置（可能在 Metabase.xml 中），您必须进行更新才能允许这么多数据通过。

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

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

于 2008-08-19T18:49:15.073 回答
2

显然，它是一个巨大的报告，实际上它比报告更接近 1.3 GB 的数据库。

您是否想过找到一种方法将其拆分为多个部分，然后将它们组合在一起？（使用几种不同的方法之一来组合本网站上列出的 PDF。）

于 2009-07-09T15:06:41.720 回答