如何使 ASP.Net MVC 控制器动作异步

Question

我的愿望是制作一个异步执行长时间运行的 i/o 操作的 MVC 控制器 Action。我的目标是避免在这个长时间运行的方法完成时占用 ASP.Net 线程池中的线程。

Action 进行了两次调用。

第一次调用是对不包含任何异步方法的第 3 方 dll。此 dll 从专有数据库中读取并执行相当复杂的 CPU 绑定处理。最多可能需要几秒钟才能返回。

第二次调用将第一次调用的结果作为参数传递给使用 Entity Framework 的数据库查询。

简单来说，这是动作：

public async Task<ActionResult> MyActionAsync(arg1, arg2)
{
    var parameters = 3rdPartyComponent.TakesLongTime(arg1, arg2);

    Task<List<MyClass>> genericList = null;

    using (DbContexts.MyDbContext db = new DbContexts.MyDbContext())
        {
          genericList = await db.Database.SqlQuery<MyClass>(sql,parameters).ToListAsync();
        }

    return View("MyView", genericList);
}

我想让对 3rdPartyComponent 的调用可以等待。我最初的想法是这样做：

var parameters = await Task.Run(() => 3rdPartyComponent.TakesLongTime()).ConfigurateAwait(false);

但我读过几位主题专家明确指出，在 asp.net MVC Action 中使用 Task.Run() 会适得其反，永远不应该这样做。

3rdPartyComponent 是编译后代码的黑盒，无法更改以添加异步方法。

有什么方法可以让 3rdPartyComponent 的调用处于等待状态，这样整个 Action 就可以在不占用 asp.net 线程池中的线程的情况下运行？

Answer 1

第一次调用是对不包含任何异步方法的第 3 方 dll。此 dll 从专有数据库中读取，并执行相当复杂的 cpu-bound 处理。

我想等待 3rdPartyComponent 的调用。

有什么方法可以让 3rdPartyComponent 的调用处于等待状态，这样整个 Action 就可以在不占用 asp.net 线程池中的线程的情况下运行？

代码已经可以做到最好了。 Task.Run 和 Task.Factory.StartNew 都不会给您带来任何好处（即使您通过了 LongRunning 标志）。

由于 3rd-party dll 执行 CPU-bound 代码，它需要一个线程。即使可以修改，也只能使数据库访问（I/O 工作）异步；根据定义，CPU 工作是同步的，根据您的描述，听起来大部分时间都是受 CPU 限制的工作。

在 ASP.NET 上避免 Task.Run（以及更糟糕的 Task.Factory.StartNew）的全部意义在于它们会导致效率较低的行为。通过释放 ASP.NET 请求线程，您只是将一个未使用的线程返回到线程池； ASP.NET 请求线程没有什么神奇或特别之处。所以Task.Run通过切换到另一个线程池线程来释放一个线程池线程，Task.Factory.StartNew和LongRunning通过创建一个全新的线程来释放一个线程池线程，将工作安排到那个线程，然后拆除它最后的线程（此行为未记录或指定，但它是当前观察到的行为）。

所以你最终做的只是导致不必要的线程切换（在StartNew 的情况下，一个完整的额外线程）。 ASP.NET 旨在处理同步和异步工作；如果你有同步代码，最好的办法就是直接执行它，就像你的代码已经在做的那样。

Answer 2

是的，我认为在异步服务器方法中使用 Task.Run 是一种反模式，因为您安排的工作最终只会在线程池中重新排队，而这正是您刚刚来自的地方。 .. 净增益为零（减去在线程池中调度回调的开销）。

我的第一个想法是开始工作

Task.Factory.StartNew(action,TaskCreationOptions.LongRunning)

TaskCreationOptions.LongRunning 暗示工作应该在新线程而不是线程池中完成。

...但是，如果这是一种流量大的方法，那么创建线程的速度会比清除线程的速度快，现在您已经失去了线程池的管理优势。

如果流量真的像你说的那样高并且需要这种特殊处理，则可能需要进行某种限制和/或缓存......但这将是一个不同的问题......