处理长时间运行的报告

在这里使用文件系统可能是一个不错的选择。有一个立即返回报告pdf位置的url的请求。然后，您的服务器可以启动外部进程，也可以向自己发送请求以执行报告。客户端可以（使用http HEAD）在提供的url中轮询服务器以获取PDF。如果您通过使用哈希或直接将参数放入名称中，使PDF的文件名源自报告参数，您也将获得即时服务器端缓存。

从处理的角度来看，我会考虑以某种方式使这份报告更加离线。

就像创建一个队列来放入报告请求一样，从那里处理报告，完成后，它可以向用户发送消息。

也许我甚至会创建一个单独的Windows服务来处理队列。

更新：发送给用户可以是电子邮件，也可以有一个"报告"页面，在那里他们可以检查报告的状态，并在准备好后下载。

将报告通过电子邮件发送给用户怎么样。asp页面所要做的就是发送生成报告的请求，并返回一条消息，即在完成运行后将通过电子邮件发送报告。

您的用户可能不接受这种方法，但是：

当他们请求报告时（通过单击按钮或链接或其他方式），你可以在一个单独的线程上启动报告生成过程，并将用户重定向到一个页面，上面写着"谢谢，你的报告将在几分钟后通过电子邮件发送给你"。

当线程生成报告后，您可以直接通过电子邮件发送PDF（可能由于大小原因无法工作），或者将报告保存在服务器上并通过电子邮件向用户发送链接。

或者，您可以进入IIS并将超时时间提高到>3分钟。

如果遇到这个问题，我会做一些事情：

1-停止超时！它们完全是在浪费资源。（调出asp页面的超时值）

2-将所有数据库访问集中在一个点上，然后收集关于谁运行了什么报告以及运行了多长时间的统计数据。调查为什么需要这么长时间，是因为报告的复杂性吗？数据范围？服务器负载？（实际上，您可以将其写在服务器上的.csv文件上，并定期将该文件导入sql server中，以便稍后进行分析）。

最终，如果你通过这个单一的访问点，你将更容易"缓存"报告（例如，相同的查询相同的日期将返回以前生成的相同PDF）

3-我知道这真的不是问题所在，但你有没有试过深入研究这些问题，看看为什么它们运行时间这么长？也许是查询调优？

4-当报告准备好时，电子邮件/短信/屏幕消息似乎很棒。。。如果你的用户通常会发送一批要生成的报告，也许可以在应用程序中构建一个指示"他们"队列进展的小仪表板。一个小的ajax控件会定期刷新状态。。提示：如果你使用了中央数据库访问，并且你有足够的信息来了解运行什么、为什么运行以及运行多长时间，你最终将能够大致估计运行报告所需的时间。

如果响应时间是关键任务，那么在一天中的某些时间内，某些用户的数据范围（例如日期范围）是否应该受到限制？

祝你好运，如果你想得到更准确的提示，请发布更多关于你的场景的细节。。。

查询调优可能是您的最佳起点。虽然我不知道你正在生成报告，但这一步应该不会花那么长时间。另一方面，性能不佳的查询可能会完全影响您的性能。

根据您在查看查询时发现的情况，您可能需要添加一些索引，甚至可能需要设置一个表来以非规范化的方式存储报表的信息，以使其更快地可用。然后，这个非规范化的表可以每小时刷新一次（通过SQL Server作业），或者按照您的要求（在合理的范围内）以任何频率刷新。

如果它是一个相对静态的报告，没有不同的用户输入参数，那么缓存当天早些时候运行的报告也是一个好主意，但在不了解您的情况的情况下，很难对此发表更多意见。

对于这样的问题，您确实需要从数据库开始，除非您有理由怀疑您的报告生成代码是罪魁祸首。你可以使用各种创可贴，这可能会在一段时间内有所帮助，但如果你的数据库是根本原因，那么这些解决方案将无法很好地扩展，你可能会在未来的某个时候遇到类似的问题（甚至更糟）。