C# 处理长时间运行的报告

我正在使用Sql Server 2000数据库开发一个用C#编写的ASP.net应用程序。我们有几个PDF报告供客户用于其业务需求。问题是生成这些报告需要一段时间（>3分钟）。通常情况下，当用户请求报告时，请求超时会在web服务器有时间完成报告生成之前终止请求，因此用户永远没有机会下载文件。然后，用户将刷新页面并重试，这将重新启动整个报告生成过程，但最终仍然超时。（不，我们现在不缓存报告；这是我正在努力争取的…）

您如何处理这些场景？我脑子里有一个想法，就是提出一个即时请求，开始生成报告，然后使用一些javascript定期检查状态。一旦状态指示报告已完成，则单独请求实际文件

---

有没有一种我没有看到的更简单的方法？

将报告通过电子邮件发送给用户怎么样。ASP页面应该做的是发送请求生成报告，并返回一个消息，报告在完成运行后将被电子邮件发送。

< P>我会考虑从处理的角度使这个报告更加离线。

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

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

---

更新：发送给用户的方式可以是电子邮件，也可以是“报告”页面，用户可以在该页面上检查报告的状态，并在准备好后下载报告。

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

当他们请求报告时（通过单击按钮、链接或其他方式），您可以在单独的线程上启动报告生成过程，并将用户重新引导到一个页面，该页面上写着“谢谢，您的报告将在几分钟内通过电子邮件发送给您”

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

---

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

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

如果出现此问题，我会做以下几件事：

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

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

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

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

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

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

---

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

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

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

如果它是一个相对静态的报告，没有变化的用户输入参数，那么缓存当天早些时候运行的报告也是一个好主意，但是在不了解您的情况下很难再谈论这个问题

---

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

这是我的第一个想法，但我们系统的用户不需要有电子邮件地址。另外，这是一个很好的建议。您能否详细说明客户端如何使用http头轮询服务器。然而，我喜欢投票的想法