gpt4 book ai didi

c# - 尽管线程池中有足够的线程,但请求仍在 Azure AppService 中排队

转载 作者:太空狗 更新时间:2023-10-30 00:29:52 32 4
gpt4 key购买 nike

我使用asp.net webapi编写了一个api,并将其部署在azure中作为Appservice。我的 Controller 的名称是 TestController,我的操作方法如下所示。

    [Route("Test/Get")]
public string Get()
{
Thread.Sleep(10000);
return "value";
}

因此,对于每个请求,它应该等待 10 秒,然后返回字符串“value”。我还编写了另一个端点来查看线程池中用于执行请求的线程数。该 Action 如下所示。

    [Route("Test/ThreadInfo")]
public ThreadPoolInfo Get()
{
int availableWorker, availableIO;
int maxWorker, maxIO;

ThreadPool.GetAvailableThreads(out availableWorker, out availableIO);
ThreadPool.GetMaxThreads(out maxWorker, out maxIO);

return new ThreadPoolInfo
{
AvailableWorkerThreads = availableWorker,
MaxWorkerThreads = maxWorker,
OccupiedThreads = maxWorker - availableWorker
};
}

现在,当我们同时向 Test/Get 端点发出 29 个 get 调用时,几乎需要 11 秒才能成功所有请求。因此服务器在 11 个线程中并发执行所有请求。要查看线程状态,请在调用 Test/Get 后立即调用 Test/ThreadInfo 返回(无需等待){ “可用工作线程”:8161, “最大工作线程数”:8191, “占用线程”:30}

似乎有 29 个线程正在执行 Test/Get 请求,1 个线程正在执行 Test/ThreadInfo 请求。

当我对 Test/Get 进行 60 次 get 调用时,几乎需要 36 秒才能成功。调用 Test/ThreadInfo(需要一些时间)返回{ “可用工作线程”:8161, “最大工作线程数”:8191, “占用线程”:30}

如果我们增加请求数,OccupiedThreads 的值就会增加。与 1000 个请求一样,需要 2 分 22 秒,OccupiedThreads 的值为 129。

尽管 WorkerThread 中有很多线程可用,但似乎在 30 个并发调用后请求并排队。它逐渐增加并发执行的线程,但这还不够(129 个线程用于 1000 个请求)。

由于我们的服务有大量的 IO 调用(其中一些是外部 api 调用,一些是数据库查询),延迟也很高。由于我们使用所有 IO 调用异步方式,因此服务器可以同时处理大量请求,但当处理器执行实际工作时我们需要更多并发性。我们正在对一个实例使用 S2 服务计划。增加实例会增加并发性,但我们需要单个实例的更多并发性。

阅读有关 IIS 的一些博客和文档后,我们发现有一个设置 minFreeThreads。如果线程池中的可用线程数低于此设置的值,IIS 将开始对请求进行排队。 appservice中有这样的东西吗?是否真的可以从 azure 应用程序服务获得更多并发性,或者我们缺少一些配置?

最佳答案

我的问题终于得到答案了。问题是 ASP.NET 线程池维护了一个线程池,这些线程已经产生了线程初始化成本并且易于重用。 .NET 线程池也是 self 调整的。它监视 CPU 和其他资源利用率,并根据需要添加新线程或修剪线程池大小。当有大量请求并且池中没有足够的线程可用时,线程池开始在池中添加新线程,在此之前它运行自己的算法来查看系统的内存和 cpu 使用情况,这需要很长时间这就是为什么我们看到池中的工作线程缓慢增加并有大量请求排队的原因。但幸运的是,有一个选项可以在线程池切换到添加新线程的算法之前设置工作线程的数量。代码如下所示。

    public string Settings()
{
int minWorker, minIOC;
ThreadPool.GetMinThreads(out minWorker, out minIOC);

if (ThreadPool.SetMinThreads(300, minIOC)){
return "The minimum number of threads was set successfully.";
}
else
{
return "The minimum number of threads was not changed.";
}

}

这里ThreadPool.SetMinThreads(300, minIOC)设置在切换到添加或删除线程的算法之前线程池将创建的最小线程的值。我已添加此方法作为我的 webapi Controller 的操作,然后当我向 Test/Get 端点发出 300 个并发请求时发出请求来运行此操作后,所有请求都在 11 秒内运行并完成,并且没有请求排队。

关于c# - 尽管线程池中有足够的线程,但请求仍在 Azure AppService 中排队,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46191002/

32 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com