即使在用户通过javascript导航离开后，ASP.NET是否仍能继续可靠地处理请求

Does ASP.NET continue reliably processing a request even after a user is navigated away via javascript?

本文关键字：是否 NET 继续 请求 处理 ASP 用户 javascript 离开 导航      更新时间：2023-09-26

环境：

  • Windows Server 2003-IIS 6.x
  • ASP.NET 3.5（C#）
  • 即7,8,9
  • FF（无论最新的10个版本是什么）

用户场景：

用户根据大数据集输入搜索条件。启动请求后，他们会被导航到一个结果页面，在那里他们等待数据加载，然后可以细化数据。

技术场景：

用户发送搜索条件（通过ajax调用）后，UI调用后端服务。后端服务查询事务性系统，并将生成的数据放入数据库"缓存"中——一个非规范化的表，用于进一步细化数据（即排序、筛选）。UI等待，直到数据被缓存，然后在收到进程完成的通知后，导航到结果页面。然后，生成的页面进行调用以从非规范化表中获取数据。

问题：

对于最终不得不根据输入的标准查询许多系统的大型查询，搜索相对较慢（15-25秒）。对于其他查询来说，它相对较快（<4秒）。

技术限制：

  1. 我们不能完全重新设计这个搜索/结果系统。UI和后端的连接方式有很多复杂性。执行搜索条件后，需要翻页（因为无法在StackOverflow上解决约束）。

  2. 我们也不能要求组织在搜索之前取消对数据的规范化，因为数据必须是实时的，即如果用户在其他系统中进行了更改，那么在之后进行搜索时，数据必须正确显示。

我想要遵循的流程：

  1. 我想骗一点。我想通过fire forget模型中的异步HttpHandler发出"Cache"请求。

  2. 发出查询后，我想将页面转换到生成的页面。

  3. 在转换页面上，我想轮询"Cache"表，看看数据是否已经插入其中。

  4. 我想立即进行这种转换的原因是，生成的页面本身就很昂贵（即使没有获取数据）——甚至在调用从缓存中获取数据的服务之前，还有2秒的加载时间。

问题：

即使我使用javascript重定向离开页面，通过异步处理程序调用的ASP.NET线程是否会可靠地继续处理？

技术边界2:

是的，我知道。。。这个搜索过程听起来效率不高。我现在对此无能为力。我正在尽我所能让它表现得更好，同时我们继续研究如何重新设计它。

如果你的答案是："扔掉它，重新开始"，请不要回答。这是不能接受的。

是。

有一个属性Response.IsClientConnected，用于确定是否仍在连接长时间运行的进程。此属性的原因是，即使客户端断开连接，进程也将继续运行，并且必须通过该属性手动检测，如果过早断开连接则必须手动关闭进程。默认情况下，不会在客户端断开连接时中断正在运行的进程。

对此属性的引用：http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx

更新

仅供参考，这是一个非常糟糕的属性依赖这些天与插座。我强烈建议您采用一种方法，使您能够快速完成在某个数据库或某个长期运行任务的队列中记录的请求，可能使用RabbitMQ或类似的方法，然后在完成后使用socket.io或类似方法更新网页或应用程序。

干脆不在ASP.NET线程上执行异步操作怎么样？让ASP.NET代码调用一个服务来对数据搜索进行排队，然后使用该服务的令牌返回到浏览器，然后重定向到等待完成结果的结果页？结果页面将使用服务中的令牌进行轮询。

这样，您就不必担心ASP.NET是否会以某种方式得知浏览器已移动到另一个页面。

另一个选项是使用线程（System.Threading）
当用户发送搜索条件时，服务器开始处理页面请求，创建一个负责执行搜索的新线程，并完成返回浏览器并重定向到结果页面的响应，同时线程继续在服务器后台执行
结果页面将继续在服务器上验证查询执行是否已完成，因为启动的线程将共享进度信息。当它完成时，结果页面在完成下一次ajax调用时返回结果。

也可以考虑使用WebSockets。从某种意义上说，Web服务器本身可以告诉浏览器何时完成查询执行，因为它提供全双工通信通道。

相关文章：