ASP.NET Core/Kestrel中的线程管理 [英] Thread management in asp.net core / kestrel

问题描述

我正在使用已迁移到asp.net core 2.0的asp.net应用程序对性能/可伸缩性问题进行故障排除.我们的应用程序作为一种应用程序服务托管在azure上，在任何中等流量的情况下都非常容易掉线.

I'm troubleshooting performance / scalability issues with an asp.net app we've migrated to asp.net core 2.0. Our app is hosted on azure as an app service, and is falling over far too easily with any moderate traffic.

让我感到困惑的一件事是如何处理多个并发请求.从我在这里读到的，Kestrel使用多个事件循环来处理您的请求.但是实际的用户代码是在.net线程池上处理的(这是从此处).

One thing that's puzzling me is how multiple concurrent requests are handled. From what I've read here, Kestrel uses multiple event loops to handle your requests. But the actual user code is handled on the .net thread pool (that's from here).

因此，作为一个实验-我创建了一个新的asp.net core 2.0 MVC应用程序，并添加了一个相当讨厌的操作方法:

So, as an experiment - I've created a new asp.net core 2.0 MVC app, and added a rather nasty action method:

    [AllowAnonymous]
    public ActionResult Wait1()
    {
        System.Threading.Tasks.Task.Delay(1000).Wait();
        return new StatusCodeResult((int)HttpStatusCode.OK);
    }     

现在，当我将其推送到天蓝色时，我希望如果我同时发送100个请求，那么我应该没问题，因为100个请求听起来像是较小的负载，对吧?等待会在线程池线程上发生，对吧?

Now, when I push this to azure, I'd expect that if I send say 100 requests at the same time, then I should be OK, because 100 requests sounds like minor load, right? And the waiting will happen on the thread pool threads, right?

所以-我只是这样做，结果却很差-用红色突出显示的示例:

So - I do just this and get some rather poor results - sample highlighted in red:

嗯，不是我所期望的，每个请求大约50秒...但是，如果我更改频率，以使请求间隔一秒，那么响应时间就很好-回到您期望的1000毫秒以上.似乎如果我同时处理30个以上的请求，它就会开始受苦，这对我来说似乎有点不足.

Hmm, not what I expected, about 50 seconds per request... If however I change the frequency so the requests are spaced a second apart, then the response time is fine - back to just over 1000ms as you'd expect. It seems if I go over 30 requests at the same time, it starts to suffer, which seems somewhat low to me.

所以-我意识到我讨厌的操作方法会阻塞，但是我希望它会在线程池线程上阻塞，因此能够应付超过30个线程.

So - I realise that my nasty action method blocks, but I'd have expected it to block on a thread pool thread, and therefore be able to cope with more than my 30.

这是预期的行为吗?如果是这样，是否只是在不使用异步代码的情况下确保不做任何IO绑定工作的情况?

Is this expected behaviour - and if so is it just a case of making sure that no IO-bound work is done without using async code?

推荐答案

这是预期的行为吗?如果是这样，是否只是在不使用异步代码的情况下确保不做任何IO绑定工作的情况?

Is this expected behaviour - and if so is it just a case of making sure that no IO-bound work is done without using async code?

根据我的经验，这似乎是预期的行为.我们可以从此博客中获取答案.

Based on my experience, it seems that is as expected behaviour. We could get answer from this blog.

现在假设您正在IIS上运行ASP.Net应用程序，并且您的Web服务器共有四个CPU.假定在任何给定的时间点，有100个请求要处理.默认情况下，运行时将创建四个线程，这些线程可用于处理前四个请求.由于在 500毫秒之前不会添加任何其他线程，因此其他96个请求将不得不在队列中等待.经过 500毫秒后，将创建一个新线程.

Now suppose you are running your ASP.Net application on IIS and your web server has a total of four CPUs. Assume that at any given point in time, there are 100 requests to be processed. By default the runtime would create four threads, which would be available to service the first four requests. Because no additional threads will be added until 500 milliseconds have elapsed, the other 96 requests will have to wait in the queue. After 500 milliseconds have passed, a new thread is created.

如您所见，要赶上工作量，将需要 100 * 500ms 时间间隔.

As you can see, it will take 100*500ms intervals to catch up with the workload.

这是使用异步编程的充分理由.使用异步编程，在处理请求时不会阻塞线程，因此几乎可以立即释放四个线程.

This is a good reason for using asynchronous programming. With async programming, threads aren’t blocked while requests are being handled, so the four threads would be freed up almost immediately.

我建议您可以使用异步代码来提高性能.

I recommand that you could use async code to improve the performance.

public async Task<ActionResult> Wait1()
{
    await Task.Delay(TimeSpan.FromSeconds(15));
    return new StatusCodeResult((int)HttpStatusCode.OK);
}

我还找到了另一个

I also find another SO thread, you could refernce to it.

这篇关于ASP.NET Core/Kestrel中的线程管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！