【问题标题】:Async Controller and questions everywhere异步控制器和无处不在的问题
【发布时间】:2013-11-23 12:25:40
【问题描述】:

我有一个关于 ASP.Net MVC 4+ 中的异步控制器和操作的快速问题(使用 async/await 编程模型返回一个 Task )。 如果我的所有操作都是异步的,即使下划线操作不是 IO 绑定(例如缓慢的 Web 服务或网络通信)并且可能是 CPU 绑定,我会有什么风险。我的意思是无论代码是什么,我的所有操作都将是异步的。我希望我很清楚。

对于可能同时拥有大量用户的公共网站,是否会因同步上下文开销或任何其他重大开销而导致性能问题?

感谢您对未来的回答。

【问题讨论】:

    标签: asp.net-mvc asynchronous


    【解决方案1】:

    如果我的所有操作都是异步的,即使下划线操作不是 IO 绑定(例如慢速 Web 服务或网络通信)并且可能是 CPU 绑定,我会有什么风险。

    这正是你不想想要做的。

    考虑一下同步操作会发生什么:请求进入,ASP.NET 为该请求分配一个线程,然后该线程执行该操作。当动作完成时,同一个线程发送响应。

    现在考虑如果您将操作的 CPU 密集型工作“卸载”到线程池(例如,Task.Run)会发生什么。请求进来,ASP.NET 为该请求分配一个线程,线程开始执行操作。当线程命中Task.Run 时,它会从线程池中分配另一个 线程来执行CPU 绑定代码。然后异步操作方法针对该任务命中await,因此原始线程返回到 ASP.NET 运行时。 other 线程然后完成工作并继续发送响应。

    因此,如果您有一个异步操作将受 CPU 限制的工作推送到线程池,那么您正在为每个请求做 更多 工作。您应该永远不要在 ASP.NET 上这样做。

    我会更详细地解释这一点on my blog

    【讨论】:

      【解决方案2】:

      我认为对于一个简单的应用程序,您不会遇到任何问题,因为异步工作人员正在使用有限数量的线程运行线程池。但是您可能会遇到客户端 HTTP 线程正在等待异步响应并且超过网络网关超时的情况。例如,亚马逊 ELB 有 60 秒的超时。因此,客户端可以在异步任务仍在运行时断开连接。如果这种情况经常发生,那么您最终可能会在没有客户端响应的情况下运行和完成大量异步任务。这将是一个不幸的情况,因为您的客户端没有获取数据,而您的服务器却一无所获。

      我会考虑的一件事是您是否需要异步调用。我建议调整您的服务调用并确保它们足够快以解决负载问题,而不是使前端异步作为延迟的解决方法。例如,使用缓存。只是一个建议。

      希望对你有帮助。

      【讨论】:

      • 所以任务需要超过 60 秒才能让客户端断开连接对吗?
      猜你喜欢
      • 2021-05-11
      • 2019-03-15
      • 1970-01-01
      • 2012-10-14
      • 2015-12-03
      • 2019-05-22
      • 2014-07-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多