3

Probably there is some mess in my head, but I see a kind of confusion in the following:

  • Web API controllers are derived from the ApiController class, where the main method is ExecuteAsync, which make the request go through the pipe of filters and action, returning Task at the end;
  • Web API actions support ability to return object of type Task, utilizing TPL or async/await.

My question is: do I really benefit from constructing and runing tasks within API actions? As far as I understand, the goal to return threads back into ASP.NET threadpool ASAP is already carried out by ApiController.ExecuteAsync infrastructure, therefore additional level of async gives me nothing (except if I need cancellation for task or performing operations in backend in parallel).

Any thoughts? Thanks.

Improve this question

1 Answer 1

Reset to default
5

As with any parallel programming the answer is unfortunately: it completely depends on the kind of processing you're doing.

For starters, the ASP.NET runtime is already providing concurrency per request. Therefore if the work you're doing is entirely compute bound then there is very little benefit to using async. The exception to that rule is if the data your processing in the request is very large and, thus, would benefit from further concurrency.

The most important scenarios where it does make sense to use async is when you're doing any kind of I/O work (disk I/O or network I/O). For example when your ASP.NET controller code...

  • communicates with another backend web service
  • communicates with the database server
  • reads/writes file information to the disk

You want to use async in these cases because there is wait time while the I/O requests are fulfilled: either disk or network latency. By using async you free the CPU thread that would have otherwise been blocked waiting on that data so that it can process some other compute bound work.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

I fully agree regarding I/O operations - they require async approach to be efficient. But - if I already in a job, scheduled for thread different from ASP.NET worker thread (as it seems to be in case of ApiController), whether I'll gain from scheduling a piece of job for another thread once more?
What you gain is that the worker thread doesn't have to block, which means it is free to process another request, or do any other useful work.
@svick is correct, you won't block an ASP.NET I/O thread, but it's not for free. The coordination of the handoff of the work and eventually the completion of the work and signaling back to ASP.NET to send the response is probably not worth the overhead. Again, there is no one answer to these kinds of questions, the only way to know is to measure your specific case.
@DrewMarsh I thought the whole point of C# 5's async-await is that it is worth it, most of the time.
@svick No, everything has to be measured... it is not always worth it. There is a price to pay in overhead in allocating and scheduling tasks and coordinating communication between threads as you would be doing by offloading from the original ASP.NET thread. If the work is short and entirely compute bound, staying on the original ASP.NET thread will yield the best results because you eliminate any such overhead.
|

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.