在ASP .NET MVC Web应用程序中，Task.Run是否被视为不良做法? [英] Is Task.Run considered bad practice in an ASP .NET MVC Web Application?

问题描述

我们当前正在开发一个Web应用程序，该应用程序依赖于ASP .NET MVC 5，Angular.JS 1.4，Web API 2和Entity Framework6.出于可伸缩性的原因，Web应用程序的可伸缩性依赖于async/await模式.我们的域需要进行一些cpu密集型计算，这可能需要几秒钟(< 10s).过去，一些团队成员使用Task.Run来加快计算速度，因为在ASP .NET MVC或Web API控制器内启动额外的线程被认为是不好的做法(IIS不知道该线程，因此在AppDomain Recycle上考虑过=>参见 Stephen Cleary的博客文章)，使用过的ConfigureAwait(false).

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).

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

问题

• 在异步Web API控制器中使用Task.Run进行CPU绑定操作是否对性能有好处?
• 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?

推荐答案

使用Task.Run在异步Web API控制器中执行CPU绑定操作是否对性能有好处?

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

零.没有.实际上，您通过生成新线程来阻碍性能.在Web应用程序的上下文中，生成线程与在后台"中运行不同.这是由于Web请求的性质.当有传入请求时，将从池中获取一个线程来处理该请求.使用异步允许线程在请求​​结束之前 if 且仅在线程处于等待状态(即空闲)时返回.生成要处理的线程可以有效地使主线程空闲，从而可以将其返回到池中，但是您仍然拥有一个活动线程.在那一点上，将原始线程返回到池不会执行任何操作.然后，当新线程完成工作时，您必须从池中请求一个主线程，最后返回响应.在 all 工作完成之前无法返回响应，因此，无论您使用1个线程还是一百个线程，异步或同步，在所有操作完成之前都无法返回响应.因此，使用其他线程只会增加开销.

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.

ConfigureAwait(false)是否真的避免创建额外的线程?

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

不，或更恰当地说，不是这个. ConfigureAwait只是一个优化提示，并且仅确定在线程跳转之间是否保持原始上下文.总之，它与线程的创建无关，至少在ASP.NET应用程序的上下文中，这两种方法对性能的影响都可以忽略不计.

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.

这篇关于在ASP .NET MVC Web应用程序中，Task.Run是否被视为不良做法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！