单核心计算机上的Web API和异步/等待收益 [英] Web API and Async/Await Benefits on a Single Core Machine

问题描述

我在另一个线程中问过一个问题关于TPL(异步/等待)中GDI +的问题，讨论转向了使用TPL这样做是否有任何好处的问题.

I had asked a question in a different thread about issues with GDI+ in TPL (async/await) and the discussion turned to the question of whether or not there even were any benefits to using TPL for this.

所以我想在这里理解答案.

So I'm trying to understand the answer to that here.

场景大致是这样:

• Web API控制器/方法接收图像上传
• 调整图像大小并将其上传到天蓝色的方法会针对各种尺寸(< 10)多次调用
• 该方法为每个调整大小并上传的图像返回一个Uri
• 响应将返回到Web API客户端

请注意，这可能会在单核计算机上运行，​​因此并行运行所有调整大小(例如，缩短请求的总长度)不会有任何好处.

Note that this will likely run on a single core machine so there is no benefit to be gained by running all the resizes in parallel (to, say, shorten the overall length of the request).

但是我给人的印象是，将所有各种调整大小包装到一个方法中并异步运行 ，这至少会暂时将Web API线程返回到池中，以处理另一个请求(同时常规线程运行调整大小的任务)，那是一件好事.代码如下:

But I'm under the impression that wrapping all the various resizes into a method and running that asynchronously will at least return the Web API thread to the pool, temporarily, to process another request (while a regular thread runs the resizing tasks), and that that is a good thing. The code would look like this:

public Dictionary<ProfilePhotoSize, Uri> ProcessImages(Stream photoStream)
{
    var imgUris = new Dictionary<ProfilePhotoSize, Uri>()
    {
        ProfilePhotoSize.FiveHundredFixedWidth, ResizeAndUpload(ProfilePhotoSize.FiveHundredFixedWidth, photoStream)},
        ProfilePhotoSize.Square220, ResizeAndUpload(ProfilePhotoSize.Square220, photoStream)},
        ProfilePhotoSize.Square140, ResizeAndUpload(ProfilePhotoSize.Square140, photoStream)},
        ProfilePhotoSize.Square80, ResizeAndUpload(ProfilePhotoSize.Square80, photoStream)},
        ProfilePhotoSize.Square50, ResizeAndUpload(ProfilePhotoSize.Square50, photoStream)}
    };

    return imgUris;
}

和...

var photoUris = await Task.Run(() => _photoService.ProcessImages(photoStream);

所以问题是-我在基地之外吗?也许该理论是合理的，但实施起来不太正确(也许我需要使用ConfigureAwait)?

So the question is - am I off base? Maybe the theory is sound, but it's not implemented quite right (perhaps I need to use ConfigureAwait)?

这里的现实是什么?

推荐答案

但是，我给人的印象是，将所有各种调整大小包装到一个方法中并异步运行，这至少会暂时将Web API线程返回到池中，以处理另一个请求(而常规线程运行调整大小的任务))，那是一件好事.

But I'm under the impression that wrapping all the various resizes into a method and running that asynchronously will at least return the Web API thread to the pool, temporarily, to process another request (while a regular thread runs the resizing tasks), and that that is a good thing.

不，不是这样.如果您有真正的异步工作要做，那么可以，通过使用 async 和 await ，您将获得可伸缩性的好处.但是，您的工作受CPU限制，因此代码如下:

No, not really. If you had true asynchronous work to do, then yes, you'd get a scalability benefit from using async and await. However, your work is CPU-bound, so code like this:

var photoUris = await Task.Run(() => _photoService.ProcessImages(photoStream);

仅使用另一个线程池线程( Task.Run )结束，从而允许请求线程返回线程池.因此，这实际上是增加的开销，并没有给您带来任何可扩展性的好处.

just ends up using another thread pool thread (Task.Run), allowing the request thread to return to the thread pool. So it's actually adding overhead and doesn't give you any scalability benefit.

在ASP.NET上，如果您有CPU工作要做，只需直接调用该方法即可.不要将其包装在 Task.Run 中.

On ASP.NET, if you have CPU-bound work to do, just call that method directly. Don't wrap it in Task.Run.

这篇关于单核心计算机上的Web API和异步/等待收益的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！