ASP.NET MVC 异步控制器与服务器推送（COMET/反向 Ajax）

Question

我正在构建一个 ASP.NET MVC site，其中客户端（浏览器）可以进行最多需要 30 分钟（或更多..）处理的 API 调用。显然，我不能使用普通的 MVC 控制器来执行此操作，因为一些这样的请求会阻塞我所有的 IIS 工作线程，从而阻塞其他更快的调用。

我查看了以下两个选项：

1. ASP.NET MVC 的异步控制器
2. PokeIn 允许服务器通过反向 AJAX（长期持有旧浏览器的 HTTP 请求）或 WebSockets（来自新浏览器的 HTML5 规范）推送的库

现在这两个似乎都是一个不错的可行选择。

选项 1 对我来说似乎最容易实现。使用异步控制器，我的 IIS 工作线程不会被阻塞，因此我的其他更快的 API 调用可以无缝通过。但是，从异步控制器documentation 来看，我认为它会产生另一个非 IIS 线程，该线程将被阻塞/等待我长时间运行（30~ 分钟）的进程完成。我读到过，“如果你在控制器中阻塞或休眠，无论它是异步还是非异步，都是非常糟糕的。”

在选项 2 中，如果我的客户端使用支持 WebSockets 的较新浏览器，这可能是最高效的，因为我不需要在服务器端设置任何阻塞线程。当客户端触发缓慢的 API 调用时，我会引发一个事件，在该事件完成后（比如 30 分钟后），我会引发另一个事件，以使用更新的内容更新我所有客户端的浏览器。 但是，对于 PokeIn 库，如果我的部分客户端没有支持 WebSocket 的浏览器（旧的..），我不确定他们是否会占用我的 IIS 工作线程之一。

选项 2 是否符合我的要求？ 在选项 1 中让我的异步控制器等待慢速进程是不是很糟糕？ 选项 1 的另一个缺点是，如果用户在请求完成之前刷新页面，一旦完成，他将不再获得作业的更新！

欢迎提出任何想法和建议。

谢谢

Answer 1

PokeIn 使用相同的内存/线程池来推送 websocket 和 ajax 连接的消息，因为它具有内部 websocket 服务器。 ajax 和 websocket 的交付时间当然不同，但无论您选择哪种方法/选项，您都会有这种差异。此外，您可能已经知道，但 Pokein 回退到 Comet ajax 以防客户端不支持 websocket 而您不必处理它。

希望这能回答您对选项 2 的问题。