看来，它们存在的唯一原因是，可以保存IIS线程，而长时间运行的工作委托给正常的CLR线程，似乎更便宜。
我在这里有几个问题：
>为什么这些IIS线程这么昂贵以证明这个整体架构支持异步控制器？
>我如何知道/配置在我的IIS应用程序池中运行多少个IIS线程？
解决方法
磁盘I / O，Web服务调用，都被阻塞。有最好通过使用异步调用优化。当你进行异步调用时，asp.net释放你的线程，当调用回调函数时，请求将被分配给另一个线程。
要配置可以设置的线程数：
<system.web>
<applicationPool maxConcurrentRequestsPercpu="50" maxConcurrentThreadsPercpu="0" requestQueueLimit="5000"/>
</system.web>
参考：ASP.NET Thread Usage on IIS 7.5,IIS 7.0,and IIS 6.0
这些设置为Microsoft best practices recommend：
>将maxconnection设置为12 *#of cpus。此设置控制您可以从客户端启动的传出HTTP连接的最大数量。在这种情况下，ASP.NET是客户端。将maxconnection设置为12 *#of cpus。
>将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，但它仅适用于来自本地计算机的本地主机请求。将minLocalRequestFreeThreads设置为76 *#的cpu。
注意：本节中提供的建议不是规则。他们是一个起点。
您必须对您的应用程序进行基准测试，以找到最适合您的应用程序的应用程序。
