63

Background

We are currently developing a web application, which relies on ASP .NET MVC 5, Angular.JS 1.4, Web API 2 and Entity Framework 6. For scalability reasons, the web application heavility relies on the async/await pattern. Our domain requires some cpu-intensive calculations, which can takes some seconds (<10s). In the past some team members used Task.Run, in order to speed up the calculations.Since starting an extra thread inside ASP .NET MVC or Web API controllers is considered a bad practise (the thread is not known by the IIS, so not considered on AppDomain Recycle => See Stephen Cleary's blog post), they used ConfigureAwait(false).

Example

public async Task CalculateAsync(double param1, double param2) { // CalculateSync is synchronous and cpu-intensive (<10s) await Task.Run(() => this.CalculateSync(param1, param2))).ConfigureAwait(false); }

Questions

  • Is there any performance benefit in using Task.Run in an async Web API Controller for cpu-bound operations?
  • Does ConfigureAwait(false) really avoid the creation of an extra thread?
Improve this question
2
  • 4
    Task.Run is not creating a thread but is using Thread Pool I think. Commented Nov 17, 2015 at 18:35
  • Ah you are absolutely right! Thanks for the correction. Commented Nov 17, 2015 at 20:26

4 Answers 4

Reset to default
82

Is there any performance benefit in using Task.Run in an async Web API Controller for cpu-bound operations?

Zero. None. In fact, you're hindering performance by spawning a new thread. Within the context of a web application, spawning a thread is not the same thing as running in the "background". This is due to the nature of a web request. When there's an incoming request, a thread is taken from the pool to service the request. Using async allows the thread to be returned before the end of the request, if and only if the thread is in a wait-state, i.e. idle. Spawning a thread to do work on, effectively idles the primary thread, allowing it to be returned to the pool, but you've still got an active thread. Returning the original thread to the pool does nothing at that point. Then, when the new thread finishes its work, you've got to request a main thread back from the pool, and finally return the response. The response cannot be returned until all work has completed, so whether you use 1 thread or a hundred, async or sync, the response cannot be returned until everything finishes. Therefore, using additional threads does nothing but add overhead.

Does ConfigureAwait(false) really avoid the creation of an extra thread?

No, or more appropriately, it's not about that. ConfigureAwait is just an optimization hint, and only determines whether the original context is maintained between thread jumps. Long and short, it has nothing to do with the creation of a thread, and at least in the context of an ASP.NET application, has negligible performance impact either way.

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

11 Comments

Ah many thanks for the detailed explanation! So it is just better to just use Task.FromResult to invoke the synchronous method "CalculateSync" from the async method "CalculateAsync" and block the thread for <10s. Right?
@Fabe: No. Just drop CalculateAsync completely and use CalculateSync instead.
@Fabe Just to clarify.. no thread is created (or "spawned") when using Task.Run without the LongRunning flag.
@i3arnon: Many thanks! This flag is new to me, have to look it up in MSDN. If I could, I would both yours and Chriss Pratts answer as most helpful ;-)
I didn't get this part of answer."Using async allows the thread to be returned before the end of the request, if and only if the thread is in a wait-state, i.e. idle.".As far as I understand main threads return to application pool but because it has started a new thread,it has to wait until that thread finishes its job.So until all threads spawned by our main finishes job,main thread can't serve for new requests.Is it true ?
|
28

Is there any performance benefit in using Task.Run in an async Web API Controller for cpu-bound operations?

No. And it doesn't matter whether it's CPU bound or not.

Task.Run offloads work to a ThreadPool thread. The web api request already uses a ThreadPool thread so you're just limiting scalability by offloading to another thread with no reason.

This is useful in UI apps, where the UI thread is a special single thread.

Does ConfigureAwait(false) really avoid the creation of an extra thread?

It doesn't affect thread creating in one way or another. All it does is configures whether to resume on the captured SynchronizationContext or not.

Improve this answer

12 Comments

Many thanks! Same question as to Chris Pratt: So it is just better to just use Task.FromResult to invoke the synchronous method "CalculateSync" from the async method "CalculateAsync" and block the thread for <10s. Right?
@Fabe just call the synchronous method directly. If there's no asynchronous operation you don't need a task to begin with.
@Fabe CalculateAsync is pointless and shouldn't exist. If you need to offload CalculateSync to a different thread let the consumer use Task.Run themselves.
Ok but if the consumer is a web api controller hosted in IIS and called by angular, i should not use Task.Run there, right?
@Fabe No. You only want to offload to a different thread when you have a "special" thread (e.g. a UI app). Web API doesn't have that.
|
14

Is there any performance benefit in using Task.Run in an async Web API Controller for cpu-bound operations?

Think about what really happens - Task.Run() creates a Task on the thread pool, and your await operator will free the thread (I'm assuming all methods down the stack are also awaiting). Now your thread is back to the pool, and it might pick up that same Task! In this scenario, there is obviously no performance gain. There is performance hit, actually. But if the thread picks up another Task (that's probably what will happen), another thread would have to pick up CalculateSync() Task and continue from where the former stopped. It would have made more sense to let the original thread execute CalculateSync() in the first place, no Tasks involved, and let the other thread have the other queued Tasks.

Does ConfigureAwait(false) really avoid the creation of an extra thread?

Not at all. It merely points out that the continuation shouldn't be executed on the caller's context.

Improve this answer

1 Comment

Many thanks! Same question as to Chris Pratt and i3arnon: So it is just better to just use Task.FromResult to invoke the synchronous method "CalculateSync" from the async method "CalculateAsync" and block the thread for <10s. Right?
2

There is one more thing that you need to consider. As you told your your api is doing CPU intensive task then async/await help to run the process in another thread and free your app pool for another request. Means your web api can handle more number of request per second if you use async/await correctly.

In your case look like this.CalculateSync(param1, param2) is non-async method so to call this asynchronously you have to use Task.Run.

I'll recommend to remove .ConfigureAwait(false) as this will actually decrease your performance.

Improve this answer

3 Comments

But wouldn't it be better to just use Task.FromResult?
Task<T> is implicitly convertable to Task, so just to get a completed Task<T> (with any T and any value) and use that. You can use Task.FromResult
Why would .ConfigureAwait(false) decrease performance? Wouldn't it increase performance since it prevents a useless synchronization context switch back to the original context?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.