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

IO and CPU Bound calls with Async APIController in a Four layers application

我有一个四层应用程序：

  1. HTMLUI层对UI服务进行AJAX调用（网络API控制器） .
  2. UI 服务 这是一个 Web API 控制器。 UI 服务调用应用服务。
  3. App Service 层，它具有通过 EF 直接调用数据库以及调用其他域服务（Web APIs）的方法。
  4. 域服务 也是 Web API。

第一层、第二层和第三层托管在一台机器上。域服务托管在不同的机器上。 SQL 服务器托管在另一台服务器上。

我的问题是：

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

  2. 从应用服务到领域服务的调用是否IO Bound因为调用通过网络？从应用服务到数据库的调用也是这样吗？

  3. 我是否应该将所有方法都设为基于 async/await 的任务以利用可扩展性？我所说的可伸缩性是指 IIS HTML UI 层，UI 服务和应用程序服务 已托管可以处理更多请求吗？

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

  5. 如果我有一个异步 APIController，在网站流量大的情况下会发生什么？尽管 IIS 可以处理所有请求但它们都在排队，但所有用户都会看到 UI 吗？

  1. 通过网络进行的调用是与调用方绑定的 IO。被调用方存在何种边界取决于实现。
  2. 是的。
  3. "can process more requests" 如果您同时处理的请求数（在同一时间点）超过 100，您 可能 开始看到异步的好处。在那之前吞吐量收益是负的（更多的 CU 负载）并且生产力成本是不小的。
  4. 请求排队，产生越来越多的线程。这可能导致死亡。您遇到此问题的情况是有限的。您可能没有 100 个并发请求，因为这可能会使您的服务器超载 10 倍。服务器上异步的主要情况是缓慢的后端服务（如 Web 服务或 Azure 的东西）。
  5. 只有当应用程序能够处理负载时，所有响应才会到达。这是很合逻辑的。如果线程池（如果配置正确）无法处理所有未完成的工作，异步只会让您获得更多吞吐量。几乎从来没有这种情况。

讨论什么时候使用异步比较好我以前的帖子： Does async calling of web service make sense on server?