我遇到的情况是,ASP.NET需要很长时间才能生成网页回复(超过2小时)。它由于代码隐藏运行一段时间(非常长,慢循环)。
浏览器(IE和Firefox)停止等待回复(大约一小时后),并且通用无法显示网页错误(类似于您尝试导航到不存在的服务器时所看到的)。
同时asp.net应用程序继续运行(我可以在调试器中看到它)并最终完成。
为什么会这样? web.config中是否有任何设置来影响这个?我希望有一个超时设置我错过了导致这种情况。
也许是IE或Firefox中的设置?但我认为他们等待服务器保持连接活着。
即使我在VS的本地计算机上以调试模式(使用编译debug =“true”)启动应用程序(因此它不在IIS上运行,但在ASP.NET Dev Server上运行),我也遇到了这种情况。
我知道生成页面花了这么长时间是很糟糕的,但在这个阶段并不重要。加快它将需要大量的额外工作,延迟并不重要。这在内部使用。
我意识到我可以围绕这个问题重新设计运行逻辑到后台进程,并在通过AJAX完成时收到通知,或将其拉到桌面应用程序或服务或其他任何东西。这些方面的东西最终会完成,但这不是我现在要问的。
答案 0 :(得分:6)
听起来你正在使用IE,它在等待来自服务器的响应时超时。
您可以找到一篇Technet文章来调整此限制:
http://support.microsoft.com/kb/181050
原因
按照设计,Internet Explorer强制执行 服务器的超时限制 返回数据。超时限制是 版本4.0和4.01五分钟 版本5.x,6为60分钟, 7.因此,Internet Explorer 不会无休止地等待服务器 当服务器返回数据时 有问题。回到顶端
解决方案
一般情况下,如果页面内部没有返回 分钟,很多用户认为是 问题已经发生并停止了 处理。因此,设计您的服务器 进程在5中返回数据 分钟,以便用户不必 等待很长一段时间。
答案 1 :(得分:4)
Web的整个范例是请求/响应。不要求,等待两个小时,回复!
如果工作需要很长时间,那么让页面请求触发工作,然后不要等待它。将长时间运行的代码放入Windows服务,并让服务侦听MSMQ队列(或使用带有MSMQ端点的WCF)。让页面将工作请求发送到此队列。该服务将读取请求,可能启动一个新线程来处理它,然后将响应写入另一个队列,文件或其他任何内容。
相同的页面或不同的“进度”页面可以轮询响应队列或文件以获取响应,并更新用户,假设用户在两小时后仍然关心。
答案 2 :(得分:3)
对于需要这么长时间的事情,我会想办法通过AJAX启动它,然后定期检查它的状态。后台进程应定期更新某个状态变量,并在完成后将其数据存储在缓存或会话中。当它完成并且浏览器检测到这一点(通过AJAX)时,让浏览器进行真正的回发(或通过更改location.href来获取),选择保存的数据并生成页面。
答案 3 :(得分:0)
我有一个过程,可能需要几分钟,所以我分拆一个单独的线程并通过ftp发送结果。如果在进程中发生错误,我会向自己发送包含堆栈跟踪的错误消息。您可能需要考虑通过电子邮件或其他地方然后通过浏览器发送结果并使用线程。