在四层应用程序中使用Async APIController进行IO和CPU绑定调用

Question

我有一个四层应用程序：

1. HTML UI图层对UI服务（Web APIController）进行AJAX调用。
2. UI服务，这是一个Web API控制器。 UI服务调用App Service。
3. App Service 图层，其中包含通过EF直接调用数据库以及调用其他域服务（Web API）的方法。
4. 域名服务也是Web API。

第一层，第二层和第三层托管在一台机器上。域服务托管在不同的计算机上。 SQL Server托管在不同的服务器上。

我的问题是：

1. 如何区分 CPU绑定和IO绑定调用？是否从UI服务调用App Service， CPU绑定，因为它们存在于同一个应用程序域中？

2. 从App Service到域服务的呼叫是 IO绑定，因为呼叫是通过网络进行的？从App Service向DB发出的呼叫也是如此吗？

3. 我应该使用async / await创建所有基于TASK的方法来利用可伸缩性吗？可扩展性的意思是 HTML UI层，UI服务和应用服务托管的 IIS 可以处理更多请求吗？

4. 如果我没有异步APIController，在网站流量大的情况下会发生什么？有些用户会获得404，因为 IIS 无法处理很多请求吗？

5. 如果我有异步APIController，在网站上的繁忙交通情况下会发生什么？所有用户是否会看到UI虽然有点迟，因为 IIS 可以处理所有请求，但它们都排队了？

Answer 1

1. 通过网络进行的呼叫是IO绑定到呼叫者。被调用者存在什么样的有界性取决于实施。
2. 是
3. “可以处理更多请求”，如果您同时处理的请求数（在同一时间点）超过100，可能会开始看到异步的好处。在此之前，吞吐量效益为负（更多CU负载），生产力成本非常重要。
4. 请求排队，越来越多的线程产生。这可能会导致死亡。您可以解决此问题的情况是有限的。您可能没有100个并发请求，因为这可能会使您的服务器超载10倍。服务器上异步的主要情况是慢后端服务（如Web服务或Azure内容）。
5. 只有当应用程序可以处理负载时，所有响应才会到达。这很合乎逻辑。如果线程池（如果配置正确）无法处理所有未完成的工作，则Async仅为您提供更多吞吐量。这几乎不是这种情况。

有关在以前的帖子中使用异步的好处的讨论：https://stackoverflow.com/a/25087273/122718 https://stackoverflow.com/a/12796711/122718 Does async calling of web service make sense on server?