我正在使用带有 Sql Server 2000 数据库的 C# 编写的 ASP.net 应用程序。我们有几份 PDF 报告供客户用于满足他们的业务需求。问题是这些报告需要一段时间才能生成（> 3 分钟）。通常最终发生的情况是，当用户请求报告时，请求超时会在 Web 服务器有时间完成生成报告之前终止请求，因此用户永远没有机会下载文件。然后用户将刷新页面并重试，这将重新开始整个报告生成过程，但仍然会超时。（不，我们现在不缓存报告；这是我正在努力争取的……）。
你如何处理这些场景？我的脑海中有一个想法，它涉及发出异步请求以开始生成报告，然后使用一些 javascript 来定期检查状态。一旦状态表明报告已完成，然后对实际文件发出单独的请求。
有没有我没有看到的更简单的方法？
在这里使用文件系统可能是一个不错的选择。有一个立即返回报告 pdf 位置的 url 的请求。然后，您的服务器可以启动外部进程或向自身发送请求以执行报告。客户端可以在提供的 url 处轮询服务器（使用 http HEAD）以获取 PDF。如果您使 PDF 的文件名从报告参数派生，通过使用哈希或直接将参数放入名称中，您也将获得即时服务器端缓存。
从处理的角度来看，我会考虑以某种方式使这份报告更加离线。
就像创建一个队列来放入报告请求，从那里处理报告，完成后，它可以向用户发送消息。
也许我什至会为队列处理创建一个单独的 Windows 服务。
更新：可以通过电子邮件发送给用户，或者他们可以有一个“报告”页面，在那里他们可以检查他们的报告状态并在准备好时下载它们。
如何通过电子邮件将报告发送给用户。所有 asp 页面应该做的是发送生成报告的请求并返回一条消息，报告将在完成运行后通过电子邮件发送。
您的用户可能不接受这种方法，但是：
当他们请求报告时（通过单击按钮或链接或其他方式），您可以在单独的线程上启动报告生成过程，并将用户重定向到显示“谢谢，您的报告将通过电子邮件发送到几分钟后给你”。
当线程完成生成报告后，您可以直接通过电子邮件发送 PDF（由于大小可能无法正常工作），或者将报告保存在服务器上并将链接通过电子邮件发送给用户。
或者，您可以进入 IIS 并将超时时间提高到 > 3 分钟。
如果我遇到这个问题，我会做以下一些事情：
1-停止那些超时！他们完全是在浪费资源。（调出asp页面的超时值）
2-将所有数据库访问集中在一个点上，然后收集有关何时由谁运行的报告以及花费了多少时间的统计信息。调查为什么需要这么长时间，是因为报告的复杂性吗？数据范围？服务器负载？（实际上，您可以将其全部写在服务器上的 .csv 文件中，并定期将此文件导入 sql server 以供稍后分析）。
最终，如果您通过这个单一访问点，您将更容易“缓存”报告（例如，相同的查询相同的日期将返回先前生成的相同 PDF）
3-我知道这确实不是问题，但您是否尝试过深入研究这些查询以了解为什么它们运行时间如此之长？查询调整可能吗？
4- 报告准备就绪时的电子邮件/短信/屏幕消息似乎很棒......如果您的用户通常发送要生成的一批报告，则可能会在应用程序中构建一个指示“他们的”队列进展的小仪表板。一个小的 ajax 控件会定期刷新状态。提示：如果你使用了中央数据库访问，并且你有足够的信息知道什么时候为什么运行以及运行多长时间，你最终将能够粗略估计报告所需的时间跑步。
如果响应时间是关键任务，是否应该在一天中的几个小时内将某些用户限制在数据范围（例如日期范围）内？
祝你好运，如果您想获得更准确的提示，请发布有关您的场景的更多详细信息......
查询调优可能是您最好的起点。虽然我不知道您正在生成报告，但该步骤不应该花费那么长时间。另一方面，性能不佳的查询绝对会影响您的性能。
根据您在查看查询时发现的内容，您可能需要添加一些索引，或者甚至可能设置一个表来以非规范化的方式存储报告的信息，以使其更快可用。然后可以每小时（通过 SQL Server 作业）刷新此非规范化表，或者以您的要求规定的任何频率（在合理范围内）刷新。
如果它是一个相对静态的报告，没有改变用户输入参数，那么缓存在当天早些时候运行的报告也是一个好主意，但是在不了解您的情况的情况下很难说更多。
对于这样的问题，您确实需要从数据库开始，除非您有理由怀疑您的报告生成代码是罪魁祸首。您可以使用各种创可贴，可能会在一段时间内有所帮助，但如果您的数据库是根本原因，那么这些解决方案将无法很好地扩展，并且您将来可能会遇到类似的问题（或更糟） .