.Net核心Web Api异步不重要吗? [英] .Net Core Web Api Async Doesn't Matter?

查看:128
本文介绍了.Net核心Web Api异步不重要吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在使用 async 关键字编写Web Api控制器方法,并一直使用 async .我最近尝试使方法同步,以查看它如何影响性能,但震惊地发现它对任何其他http请求都没有阻塞影响.

I've been writing my Web Api controller methods with the async keyword and have been using async all the way down. I've recently tried making a method sync to see how it would affect performance and was shocked to find that it has no blocking affect on any other http request.

以例子-

[Route("Foo")]
class FooController {
  [HttpGet("Hello")]
  public string GetHello()
  {
    Thread.Sleep(100000); // 100 seconds
    return "Hello";
  }

  [HttpGet("Goodbye")]
  public string GetGoodbye()
  {
    return "Goodbye";
  }
}

这样,我可以运行 GET => /Foo/Hello ,然后运行任意数量的 GET => /Foo/再见,并且我对 Goodbye 端点的请求没有任何阻塞.

With this I can run GET => /Foo/Hello followed by any number of GET => /Foo/Goodbye and there is no blocking on my requests to the Goodbye endpoint.

我本来以为需要 使Hello方法异步,以便对Goodbye端点的请求将立即返回.但是使此方法同步/异步无效!

I originally thought that I'd be required to make the Hello method async so that requests to the Goodbye endpoint would return without delay. But making this method sync/async has no effect!

非常困惑.Web Api应用程序不需要异步吗?为什么推荐?

Very confused. Do Web Api applications not require async? Why is it recommended?

推荐答案

这不是那么简单.

有些东西叫做线程池.对您的应用程序的每个请求都分配给一个从线程池中提取的单独线程.这是一个请求不会阻止另一个请求的第一个原因.

There is something called Thread pool. Each request to your application get assigned to a separate thread taken from the thread pool. This is the first reason why one request doesn't block the other.

现在,当您的流量较低时,一切都会好起来,这样您就不会达到线程池中线程的限制数量.但是...

Now, everything is well and good when you have low traffic so you're not hitting the limit number of threads in thread pool. But...

为便于讨论,假设您的请求平均需要1秒,并且线程池的大小为100.您将开始遇到第101个请求的限制.该线程由于没有要分配的线程池,因此必须等待第100个请求完成,然后将线程释放回线程池,然后才能对其进行处理.

For the sake of discussion, let's say your request on average takes 1 second and that you have thread pool of size = 100. You will start experiencing throttling with the 101st request. That one, since it has no thread pool to be assigned to it, will have to wait for the 100th request to finish, release the thread back to thread pool and then it can get processed.

现在,根据您的请求做什么,异步可以提供帮助(但也会引起问题,因此请不要盲目使用!):

Now, depending on what your requests do, async can help (but can also cause problems, so don't use it blindly!):

  1. 如果您的请求执行I/O操作(网络调用,文件系统,数据库异步等),则这些操作将在I/O线程上运行.这些不是来自线程池.因此,假设有一个请求传入并触发了需要0.93秒的网络调用或文件读取.实际上,这意味着,如果您不使用异步,则线程池线程在0.93秒内没有用,它只是坐在那里等待IO线程完成.在这种情况下, async 可能非常有用,因为一旦它击中了 await 关键字(与使用IO线程的操作一起使用),它将从线程池中释放线程.立即进行处理,以便可以处理下一个请求.IO操作完成后,它将从线程池中获取一个线程来提供响应.

  1. If your request does I/O operations (network calls, file system, db async, etc..) then those operations work on I/O threads. Those don't come from thread pool. So, imagine a request that comes in and fires a network call or file read that takes 0.93sec. What that in effect means is that, if you don't use async, your thread pool thread is of no use for 0.93secs and it just sits there waiting for IO thread to finish. In those cases, async can be very useful because once it hits the await keyword (which is used with operations that use IO threads) it will release the thread from the thread pool immediately so that the next request can be served. Once IO operation completes, it will get a thread from the thread pool to serve the response.

如果您的请求不使用任何IO操作,但您强迫它们使用异步(有多种方法可以执行此操作),那么您实际上要做的就是交换一个线程池线程(最初的线程池用于接受请求)再发送一个请求(该请求将运行该操作).在这种情况下,您只会增加开销并失去性能.

If your requests don't use any IO operations but you force them to use async (there are ways to do it) then all you'll effectively be doing is swapping one thread pool thread (initial one used to take the request) for another one (that will take the operation to run). In that case, you'll just create overhead and lose performance.

但是,无论如何,我的感觉与您的问题并不严格相关.在以上两种情况中的任何一种下,您的方法都在两个单独的请求中运行,与 async/await 几乎没有任何关系,但与服务器环境中独立处理请求的情况有关.

But, anyways, I have a feeling that's not strictly related to your question. In any of the above 2 scenarios, your methods are ran in 2 separate requests and have pretty much nothing to do with async/await but with the server environment where requests are processed independently.

这篇关于.Net核心Web Api异步不重要吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆