首先，我知道运行非常大/长时间运行的报告是一个可怕的想法。我知道 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 GB 内存，运行 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 keeplives
- 增加了报表服务器上的脚本超时
- 将报告设置为在服务器上永不超时
- 在客户端调用中将报告超时设置为几个小时
从我尝试过的调整来看，我相当满意地说任何超时问题都已被消除。
根据我对错误消息的研究，我认为 Web 服务 API 默认情况下不会发送分块响应。这意味着它会尝试在一次响应中通过线路发送所有 1.3GB 数据。在某个时刻，IIS 认输了。不幸的是，API 抽象了 Web 服务配置，因此我似乎无法找到启用响应分块的方法。
- 有谁知道如何在不降低总页数的情况下减少/优化 PDF 导出阶段和/或 PDF 的大小？
- 有没有办法为 SSRS 打开响应分块？
- 还有其他人有任何其他理论来解释为什么它在服务器上运行而不是通过 API 运行吗？
编辑：阅读 kcrumley 的帖子后，我开始通过文件大小/页数来查看平均页面大小。有趣的是，在较小的报告上，经过数学计算，每页大约为 5K。有趣的是，当报告变大时，这个“平均值”就会增加。例如，一份 8000 页的报告平均每页超过 40K。很奇怪。我还要补充一点，除了每个分组中的最后一页之外，每页的记录数都是设置的，因此不会出现某些页面的记录多于其他页面的情况。
