当代码的所有部分都不是异步时，异步Web服务有什么好处

我想知道如果不是代码的所有部分都是异步的，那么使用异步http请求会带来多少好处。

让我们考虑一下场景：1）异步http请求阻塞同步数据库调用，以及2）同步等待异步数据库调用的http请求。

1）Web Api支持异步操作方法，但是如果我在处理请求时执行同步数据库调用，那么线程会阻塞调用，并且我不会获得async可以给我的更好的线程经济性的好处或什么？

2）如果我有一个等待异步数据库调用的同步ServiceStack服务调用，那么会发生什么？我假设一个线程被保留用于处理整个同步http请求，当这个线程等待异步调用时，它仍然保留给Web请求或者什么？

基本上我的问题可归结为：如果不是所有的IO调用都是异步的话，有没有理由使用异步？

在服务器端，部分async解决方案通常没有任何好处。

1）Web Api支持异步操作方法，但是如果我在处理请求时执行同步数据库调用，那么线程会阻塞调用，并且我不会获得async可以给我的更好的线程经济性的好处或什么？

正确。只要执行同步（阻塞）数据库调用，就会在该调用期间占用一个线程。因此，您从async获得的好处不适用。

2）如果我有一个等待异步数据库调用的同步ServiceStack服务调用，那么会发生什么？我假设一个线程被保留用于处理整个同步http请求，当这个线程等待异步调用时，它仍然保留给Web请求或者什么？

这与同步数据库调用相同。在封面下，同步数据库调用异步执行实际调用，然后阻塞调用线程直到它完成。因此，在呼叫期间仍然会阻塞线程，并且您不会获得任何async优势。

基本上我的问题可归结为：如果不是所有的IO调用都是异步的话，有没有理由使用异步？

还有一些更加模糊的场景。您可以使用Task.WhenAll来执行有限类型的并发，与其他forms的异步并发相比，异步更容易。但如果您没有完全async堆栈，那么这是我能想到的唯一好处。

它基本上归结为调用代码在执行异步调用时可以执行的操作。你的第一个例子很适合这个。在调用save方法时，UI可以执行其他操作。在方法中幕后发生的事情并不重要……控制已经返回给应用程序以继续它的方式。

您的第二个示例仅表示servicestack服务可以在执行异步数据库调用时执行某些操作。但如果它没有做任何事情，没有任何真正的理由使用异步调用开始。

异步方法在其工作负载期间所执行的操作并不像调用应用程序在调用期间可以执行的操作那样重要。