嵌套的 async/await 调用是否会提高性能？

Question

这与 Why use Async/await all the way down 有点相关。我有一些需要维护的旧版 EF Core，其中包含许多非异步的嵌套调用。我想知道是否可以使顶级控制器仅异步并使用 Task.Run() 包装服务调用。

这两个控制器动作有什么区别。 在第一个中，EF 核心被同步调用。但是电话 包装在 Task.Run 中，所以我假设它将异步执行

第二个，EF核心调用是异步的 但是，由于控制器操作是异步的，这甚至是必要的吗？ async inside async inside async... 是否会比顶部的一个异步调用提供任何性能提升？

案例一

    //controller, async call
    public async Task<ActionList<string>> GetNames()
    {
        var names = await Task.Run(() => peopleService.GetNames());
        return Ok(names);
    }

//people service layer, no async
public List<string> GetNames()
{
    return _context.People.Where(...).Select(x => x.Name).ToList();
}

案例2

//controller, async
public async Task<ActionList<string>> GetNames()
{
    var names = await  peopleService.GetNames();
    return Ok(names);
}

//people service layer, async
public async Task<List<string>> GetNamesAsync()
{
    return await _context.People.Where(...).Select(x => x.Name).ToListAsync();
}

---

Answer 1

Task.Run 仅用于在线程池上运行您的代码。这对于 WPF 或 WinForms 应用程序很有用，因为它释放了 UI 线程以继续处理其他 UI 事件。但是，它不会在 ASP.NET 中带来任何性能优势，因为您只是将执行从一个线程池线程切换到另一个线程池线程。当遇到 EF ToList 调用时，该线程池线程将被阻塞。如果你有很多并发请求，线程池将被耗尽。 .NET 有一个线程注入策略，但这是有限的，所以一些请求会超时。如果您的负载变得非常高，您将需要如此多的线程，从而耗尽您的系统资源（CPU 和内存）。

相比之下，async-all-the-way 意味着您在数据库 I/O 操作正在进行时永远不会阻塞任何线程。每个异步操作都由底层系统处理，只有在操作完成后才会在线程池上恢复执行。这使您的系统可以扩展到更大数量的并发请求。