sql-server - 在Sql Reporting Services 2005中优化大型报表的PDF导出

Question

首先，我了解运行超大型/长期运行的报告是一个可怕的主意。我知道Microsoft有一条经验法则，指出执行SSRS报告应不超过30秒。但是，有时由于外部力量(例如遵守州法律)而产生大量报道是首选的罪恶。

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

到目前为止，除了我们最近已将25,000页的报表从Crystal报表转换为SSRS之外，SSRS的处理要比Crystal容易得多。 SSRS服务器是一台64位2003服务器，具有32个运行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);

奇怪的是，如果使用报表管理器直接在报表服务器上运行该报表，则该报表将运行/渲染/导出。生成报告数据的proc运行大约5分钟。大约12分钟后，报告将以SSRS native 格式呈现在浏览器/查看器中。通过报表管理器中的浏览器/查看器导出为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。很奇怪。我还将补充说，除了每个分组中的最后一页之外，还设置了每页的记录数，因此，在某些页面上的记录多于另一页的情况下，这不是一种情况。

Answer 1

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

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

2)除非您将SSRS配置为具有其他行为(不建议这样做)，否则SSRS会将字体或字体子集嵌入到PDF中，除非它们是5 'standard' PDF fonts之一。

尽管大多数Windows操作系统都没有现成的标准字体(我想是Symbol)，但我们发现，如果您使用Times New Roman, Courier New, or Arial，则会进行正向和反向字体替换。

转换RDL的最简单方法是将其视为XML，然后搜索并替换FontFamily标记。

如果您必须使用非标准字体，则仍可以将损坏降至最低:

使用尽可能少的字体。搜索RDL XML以确保没有多余的字体。

如果使用不同大小的字体，请使用TTF字体。

尽量不要混合字体的普通，粗体和斜体变体，否则它将被多次嵌入。