与常规 CLR 线程相比，为什么 IIS 线程如此宝贵? [英] Why are IIS threads so precious as compared to regular CLR threads?

问题描述

我正在阅读有关异步控制器的信息 在 ASP.NET MVC 中.

似乎它们存在的唯一原因是可以节省 IIS 线程，同时将长时间运行的工作委托给常规 CLR 线程，这似乎更便宜.

我有几个问题:

• 为什么这些 IIS 线程如此昂贵，无法证明为支持异步控制器而构建的整个架构是合理的?
• 我如何知道/配置有多少 IIS 线程在我的 IIS 应用程序池中运行?

解决方案

ASP.NET 使用 .NET 线程池中的线程处理请求.线程池维护一个线程池，这些线程池已经产生了线程初始化成本.因此，这些线程很容易重用..NET 线程池也是自我调整的.它监视 CPU 和其他资源利用率，并根据需要添加新线程或调整线程池大小.您通常应该避免手动创建线程来执行工作.相反，使用线程池中的线程.同时，重要的是要确保您的应用程序不会执行冗长的阻塞操作，这可能会迅速导致线程池不足和 HTTP 请求被拒绝.

磁盘 I/O、Web 服务调用都是阻塞的.最好使用异步调用进行优化.当您进行异步调用时，asp.net 会释放您的线程，并在调用回调函数时将请求分配给另一个线程.

要配置您可以设置的线程数:

<applicationPool maxConcurrentRequestsPerCPU="50" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/></system.web>

参考:IIS 7.5、IIS 7.0 和 IIS 6.0 上的 ASP.NET 线程使用

这些是微软最佳实践推荐的设置:>

• 将 maxconnection 设置为 12 * CPU 数量.此设置控制您可以从客户端发起的最大传出 HTTP 连接数.在这种情况下，ASP.NET 是客户端.将 maxconnection 设置为 12 * # 个 CPU.
• 将 maxIoThreads 设置为 100.此设置控制 .NET 线程池中的最大 I/O 线程数.该数字会自动乘以可用 CPU 的数量.将 maxloThreads 设置为 100.
• 将 maxWorkerThreads 设置为 100.此设置控制线程池中工作线程的最大数量.然后，该数字会自动乘以可用 CPU 的数量.将 maxWorkerThreads 设置为 100.
• 将 minFreeThreads 设置为 88 * CPU 数量.如果线程池中的可用线程数低于此设置的值，则工作进程将使用此设置将所有传入请求排队.此设置有效地将可以并发运行的请求数限制为 maxWorkerThreads - minFreeThreads.将 minFreeThreads 设置为 88 * # 个 CPU.这将并发请求的数量限制为 12(假设 maxWorkerThreads 为 100).
• 将 minLocalRequestFreeThreads 设置为 76 * CPU 数量.如果线程池中的可用线程数低于此数字，则工作进程将使用此设置对来自 localhost(Web 应用程序将请求发送到本地 Web 服务的请求)的请求进行排队.此设置类似于 minFreeThreads，但它仅适用于来自本地计算机的 localhost 请求.将 minLocalRequestFreeThreads 设置为 76 * CPU 数量.

注意:本节中提供的建议不是规则.他们是一个起点.

您必须对您的应用程序进行基准测试，以找出最适合您的应用程序的方法.

I'm reading about AsyncControllers in ASP.NET MVC.

It seems that the sole reason why they exist is so that the IIS threads can be saved while the long running work is delegated to regular CLR threads, that seem to be cheaper.

I have a couple of questions here:

• Why are these IIS threads so expensive to justify this whole architecture built to support asynchronous controllers?
• How do I know/configure how many IIS threads are running in my IIS application pool?

解决方案

ASP.NET processes requests by using threads from the .NET thread pool. The thread pool maintains a pool of threads that have already incurred the thread initialization costs. Therefore, these threads are easy to reuse. The .NET thread pool is also self-tuning. It monitors CPU and other resource utilization, and it adds new threads or trims the thread pool size as needed. You should generally avoid creating threads manually to perform work. Instead, use threads from the thread pool. At the same time, it is important to ensure that your application does not perform lengthy blocking operations that could quickly lead to thread pool starvation and rejected HTTP requests.

Disk I/O, web service calls, are all blocking. There are best optimized by using async calls. When you make an async call, asp.net frees your thread and the request will be assigned to another thread when the callback function is invoked.

To configure the number of threads you can set:

<system.web>
    <applicationPool maxConcurrentRequestsPerCPU="50" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>
</system.web>

Refer: ASP.NET Thread Usage on IIS 7.5, IIS 7.0, and IIS 6.0

These are the setting that Microsoft best practices recommend:

• Set maxconnection to 12 * # of CPUs. This setting controls the maximum number of outgoing HTTP connections that you can initiate from a client. In this case, ASP.NET is the client. Set maxconnection to 12 * # of CPUs.
• Set maxIoThreads to 100. This setting controls the maximum number of I/O threads in the .NET thread pool. This number is automatically multiplied by the number of available CPUs. Set maxloThreads to 100.
• Set maxWorkerThreads to 100. This setting controls the maximum number of worker threads in the thread pool. This number is then automatically multiplied by the number of available CPUs. Set maxWorkerThreads to 100.
• Set minFreeThreads to 88 * # of CPUs. This setting is used by the worker process to queue all the incoming requests if the number of available threads in the thread pool falls below the value for this setting. This setting effectively limits the number of requests that can run concurrently to maxWorkerThreads - minFreeThreads. Set minFreeThreads to 88 * # of CPUs. This limits the number of concurrent requests to 12 (assuming maxWorkerThreads is 100).
• Set minLocalRequestFreeThreads to 76 * # of CPUs. This setting is used by the worker process to queue requests from localhost (where a Web application sends requests to a local Web service) if the number of available threads in the thread pool falls below this number. This setting is similar to minFreeThreads but it only applies to localhost requests from the local computer. Set minLocalRequestFreeThreads to 76 * # of CPUs.

Note: The recommendations that are provided in this section are not rules. They are a starting point.

You would have to benchmark your application to find what works best for your application.

这篇关于与常规 CLR 线程相比，为什么 IIS 线程如此宝贵?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！