CLR ThreadPool 中繁忙工作线程的数量是否会影响 I/O 线程的性能？

Question

我们有一个Windows 服务，它托管许多WCF 服务，并且在应用程序的不相关部分中广泛使用TPL < code>Task 类异步执行相对较短的工作。

据我了解，WCF 使用 ThreadPool 中的托管 I/O 线程来执行请求。我注意到，在部署显着提高应用程序对任务的使用以及 ThreadPool 工作线程的使用的功能后，一些 Web 服务的性能变得非常慢。我们谈论的是几分钟而不是不到一秒钟。任何一次实际尝试运行的任务数量可能在 20 到 1000 之间，这让我认为任何需要一些 CPU 时间的新（最后进入）工作都可能被迫等待相当长的时间。时间。

繁忙的 ThreadPool 工作线程数量（在我的情况下非常大）是否会影响 ThreadPool 的托管 I/O 线程？这两者有什么联系吗？或者我应该开始寻找其他地方......

谢谢！

编辑：我刚刚对应用程序的实时部署进行了抽查，同时尝试调用一个长时间运行的 Web 服务，这是非常典型的：正在运行 70 个任务，Windows 服务进程有大约 150 个线程，平均 CPU 使用率 30-60%。我所说的“典型”是指 CPU 使用率一般在 40% 左右，很少超过 80%，但是有大量的任务在运行，进程使用的线程也很多。

Answer 1

注意：我以前从未回答过自己的问题，所以我希望这是合适的。请随意发表评论或不同意，但看起来其他人都没有回答这个问题。

因此，导致我们性能问题的问题是完全不相关的，现在已经解决了。

解决此问题后，Web 服务再次开始及时响应。这使我得出结论，您可以同时运行相当多的 TPL 任务（如我的示例中的数百个），并且即使大量使用线程池工作线程，WCF 仍然能够使用线程池的托管 I /O 线程有效地处理您的 Web 服务请求。

Answer 2

如果您的任务花费任意时间休眠或等待 I/O，您可能会受益于使用 TaskCreationOptions.LongRunning 启动任务。
这会导致线程池创建更多线程，而不是等待排队的线程完成。

    task = Task.Factory.StartNew(() =>
   {
       DoLongRunningWork();
   }, TaskCreationOptions.LongRunning);

如果你想测试这个概念，有一个实验这里您可能会发现有帮助。