rest api 中的 Thread.sleep 与 Task.delay

Question

我在比较 Thread.sleep 和 task.delay。 从 db 检查作业完成状态。 该作业将由其他一些 Azure 组件执行。

为了测试它，创建了具有同步和异步模式的小型 api。

http rest api 使用异步：

public async Task<HttpResponseMessage> Post()
{
    await Task.Delay(200);
    return await Task.FromResult(new HttpResponseMessage());}

http rest api 使用同步：

public HttpResponseMessage Post()
{
    Thread.sleep(200);
    return new HttpResponseMessage();}

有趣的是。 结果对同步调用很好。 使用 Apache jmeter 对 100 个用户进行了 5 次迭代尝试。

同步结果：最小：414 毫秒平均：8464 毫秒

异步结果：最小 1756 毫秒平均：10044 毫秒

为什么 Thread.sleep 比 Async 更好。 这是任务创建的开销吗？ 我不能得到比这两个更好的结果吗？

Answer 1

异步代码的重点不是提高单个操作的性能。 事实上，正如你所看到的，有时情况恰恰相反。

异步代码的要点是不锁定当前线程。 好处取决于应用程序的类型：

桌面应用程序（我知道这不适用于您，但值得一提）

在桌面应用程序中，您不会冻结 UI 线程。 这样，您的 UI 在您等待来自某些 I/O 操作的响应时仍能响应用户。

因此，虽然单个操作可能需要稍长一些的时间，但用户不会因为 UI 没有冻结而感到沮丧。

Web 应用程序

在 web 应用程序中，它释放当前线程以处理下一个进来的请求。ASP.NET 使用的线程数量有限，因此如果您的流量足够繁忙，请求可能需要等待才能处理。 异步代码可以帮助您避免这种情况。

例如，同步 I/O 操作将锁定当前线程（如Thread.Sleep ）。 在操作完成之前，线程不能做任何其他事情。

如果您使用异步代码（如Task.Delay ），则一旦该异步操作开始，线程将返回到线程池，并可用于在等待时处理另一个请求。

因此，虽然单个操作可能需要稍长的时间，但它允许您的应用程序处理更大的负载。

微软在这方面的文档实际上非常出色： Asynchronous Programming with async and await