我们有多线程的软件。一个源线程启动一堆并行任务（每个任务涉及一些处理和一些与第 3 部分 API 的对话）并等待它们中的一些或全部完成。
每个线程需要 3-30 秒来完成它的工作。
我们发现（在 prod 中）在调用ThreadPool.QueueUserWorkItem和线程实际启动之间可能存在长达 10 秒的延迟，因此我们认为线程池中可用线程的供应已经饱和。有关该限制的评论，请参见此处：System.Threading.ThreadPool.SetMaxThreads 的默认值
我们希望能够跟踪这些不同数量的线程，以便一旦我们进行了各种更改，我们就可以指出一些东西并说“看，我们已经解决了用完所有线程的问题”。
此 MSDN 页面：https ://msdn.microsoft.com/en-us/library/ff650682.aspx暗示没有计数器可以跟踪此类事情，仅提供 DIY 计数器的建议实现。
另一方面，此页面：http: //blogs.iis.net/mailant/new-worker-process-performance-counters-in-iis7说计数器确实存在吗？似乎说“最大线程数”，“总线程数”和“活动线程数”应该是相关的。我会假设这些意味着：
- “最大”：TP 可以创建多少线程，然后它必须开始等待旧线程死亡，然后才能创建新线程。
- “活动”：在任何给定时间实际有多少线程在运行我们的程序代码。
- “全部的”： ？？我猜这是“活动”+“已启动但正在等待外部资源的线程数”？在我们的例子中是第 3 方 API，但通常它可能是磁盘 IO 或数据库访问等。
我试图通过打开 Perf Monitor 来查看这些，“添加新计数器”>“W3SVC_W3WP”>选择这 3 个特定计数器>选择我们的特定进程>“添加”>“确定”。
然后 Perf Monitor 图表告诉我们： Max = 256 Total = 16 Active = 0 ！？
这似乎……不太可能？我假设我误解了计数器，或者错误配置了 Perf Monitor？
我们的下一个尝试是在任务管理器中查看进程的“线程”列（通过 IIS 管理器中的 PID 识别正确的 w3wp 进程）。这通常表明有 100-150 个线程，但如果我真的破坏了进程（向它正在运行的 API 端点发送垃圾邮件），那么我可以得到超过 256 的数字（我曾在 264 处看到它）。
任何人都可以对此有所了解吗？
从根本上说，我的问题是，所有这些不同的数字/统计数据在上下文中的具体含义是ThreadPool.QueueUserWorkItem什么，以及跟踪 ThreadPool 的线程可用性状态的最佳方法是什么。