我想知道如果代码的所有部分都不是异步的话,使用异步http请求会带来多少好处。
让我们考虑一下场景:1)异步http请求阻塞同步数据库调用,以及2)同步等待异步数据库调用的http请求。
1)Web Api支持异步操作方法,但是如果我在处理请求时执行同步数据库调用,则线程会阻塞调用,并且我将无法获得async可以提供给我的更好的线程经济性的好处什么?
2)如果我有一个等待异步数据库调用的同步ServiceStack服务调用,那么会发生什么?我假设一个线程被保留用于处理整个同步http请求,当这个线程等待异步调用时,它仍然保留给Web请求或者什么?
基本上我的问题可归结为:如果不是所有的IO调用都是异步的,是否有任何理由使用异步?
答案 0 :(得分:7)
在服务器端,部分 - async
解决方案通常没有任何好处。
1)Web Api支持异步操作方法,但是如果我在处理请求时执行同步数据库调用,则线程会阻塞调用,并且我将无法获得async可以提供给我的更好的线程经济性的好处什么?
正确。只要执行同步(阻塞)数据库调用,就会在该调用期间占用一个线程。因此,您从async
获得的好处不适用。
2)如果我有一个等待异步数据库调用的同步ServiceStack服务调用,那么会发生什么?我假设一个线程被保留用于处理整个同步http请求,当这个线程等待异步调用时,它仍然保留给Web请求或什么?
这与同步数据库调用相同。在封面下,同步数据库调用异步执行实际调用,然后阻塞调用线程直到它完成。因此,在通话期间您仍然有一个线程被屏蔽,并且您没有获得任何async
好处。
基本上我的问题可归结为:如果不是所有的IO调用都是异步的,是否有任何理由使用异步?
还有一些更加模糊的场景。您可以使用Task.WhenAll
执行有限类型的并发,使用async
比其他形式的异步并发更容易。但如果你没有完全 - async
堆栈,这是我能想到的唯一好处。
答案 1 :(得分:3)
它基本上归结为调用代码在异步调用完成时可以执行的操作。你的第一个例子很适合这个。在调用save方法时,UI可以执行其他操作。方法中幕后发生的事情并不重要......控制已经回到应用程序继续进行。
您的第二个示例意味着服务堆栈服务可以在执行异步数据库调用时执行某些操作。但如果它没有做任何事情,那么没有任何真正的理由使用异步调用开始。
异步方法在其工作负载期间所做的事情并不像调用应用程序在中所做的那样重要。