1

I have a four layer application:

  1. HTML UI layer making AJAX calls to a UI Service (Web APIController).
  2. UI Service which is a Web API controller. UI Service calls App Service.
  3. App Service layer which has methods that call database directly through EF as well as make calls to other Domain services (Web APIs).
  4. Domain Service which are Web APIs too.

The first, second and third layers are hosted on one machine. The Domain Service is hosted on a different machine. The SQL Server is hosted on a different server.

My questions are:

  1. How can I differentiate between CPU bound and IO bound calls? Are the calls made from the UI Service to the App Service, CPU bound because they exist in the same app domain?

  2. Are the calls from the App Service to the Domain Service IO Bound because the calls go through network? Is it the case with calls made from the App Service to the DB also?

  3. Should I make all the methods TASK based with async/await to take advantage of the scalability? What I mean by scalability is that the IIS where the HTML UI layer, UI Service and App Service have hosted can process more requests?

  4. What will happen under a heavy traffic on the website if I don't have async APIController? Will some users get a 404 because the IIS can't handle many requests?

  5. What will happen under a heavy traffic scenario on the website if I have a async APIController? Will all the users see the UI although it is little bit late because IIS can handle all the requests but they are all queued?

wonderful world
  • 10,969
  • 20
  • 97
  • 194

1 Answers1

0
  1. A call over the network is IO bound to the caller. What kind of boundedness is present at the callee depends on the implementation.
  2. Yes.
  3. "can process more requests" if the number of requests that you concurrently process (at the same point in time) exceeds 100 you might start to see benefits from going async. Before that point the throughput benefit is negative (more CU load) and the productivity costs are non-trivial.
  4. Requests queue up and more and more threads spawn. This can lead to death. The situations under which you can get into this problem are limited. Chances are you don't have 100 concurrent requests going because that would likely overload your servers by 10x. The prime case for async on the server is slow backend services (like web services or Azure stuff).
  5. Only if the app can handle the load will all responses arrive. That is pretty logical. Async only gets you more throughput if the thread-pool (if properly configured) was not able to process all outstanding work. This is almost never the case.

For a discussion when it is good to use async the my previous posts:https://stackoverflow.com/a/25087273/122718 https://stackoverflow.com/a/12796711/122718 Does async calling of web service make sense on server?

Community
  • 1
  • 1
usr
  • 168,620
  • 35
  • 240
  • 369
  • (1) I understand from your answer that there IS NO BENEFIT in using async APIController if all the four layers in my application are living in a single machine where is no outside network calls. (2) To clarify the answer to the question 4, let me ask it differently. If the IIS has been set up to handle 10 threads and if the async APIController is being used, any number of requests (100, 200, 300 or more) will be handled with 10 threads only and no more threads are created or may not be large enough as with a sync APIController so will perform better compared to a sync APIController. – wonderful world May 11 '15 at 22:17
  • (1) not quite. Even if the network is CPU-emulated there is still one thread waiting for the remote party to respond. You can choose to unblock that thread using async, or not. (4) assuming that IIS will not use more than 10 threads then yes you can "cheat" by using async because that returns threads to the pool. I don't know what recent ASP.NET versions use for thread management. The numbers are insanely high. Only practical problem is injection rate which can be a problem when bursts happen. Mitigate by setting mintheads to a high value. – usr May 11 '15 at 22:23
  • I understand now that with async, I'm explicitly telling the app to save a thread and use it for an incoming request if necessary. – wonderful world May 11 '15 at 22:36