小编典典

在ASP .NET MVC Web应用程序中,Task.Run是否被视为不良做法?

c#

背景

我们当前正在开发一个Web应用程序,该应用程序依赖于ASP .NET MVC 5,Angular.JS 1.4,Web API
2和实体框架6。出于可伸缩性的原因,Web应用程序的可伸缩性依赖于async /
await模式。我们的域需要进行一些CPU密集型计算,这可能需要几秒钟(<10s)。过去,一些团队成员使用Task.Run来加快计算速度,因为在ASP
.NET MVC或Web API控制器内部启动额外的线程被认为是一种不好的做法(IIS不知道该线程,因此考虑到AppDomain Recycle
=>,请参阅Stephen Cleary的博客文章),他们使用了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)是否真的避免创建额外的线程?

阅读 558

收藏
2020-05-19

共1个答案

小编典典

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

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

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

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

2020-05-19