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

时间:2011-01-11 06:50:06

标签: .net wcf clr threadpool task-parallel-library

我们有 Windows服务,其中包含许多 WCF服务,并且在应用程序的不相关部分中,广泛使用 TPL Task类以异步方式执行相对较短的工作。

据我了解,WCF使用ThreadPool中的托管I / O线程来执行请求。我注意到在部署了一个显着提高Tasks应用程序使用的功能之后,因此使用了ThreadPool工作线程,一些Web服务的性能变得非常慢。我们说的是分钟而不是一秒钟。实际上在任何时间尝试运行的Tasks的数量可以在20到1000之间,这使我认为任何需要一些CPU时间的新(最后)工作都可能被迫等待相当长的时间。 / p>

繁忙的ThreadPool工作线程(在我的情况下是非常大的)数量是否会影响ThreadPool的托管I / O线程?这两个可以以任何方式连接吗?或者我应该开始寻找其他地方......

谢谢!

编辑:我只是在尝试调用其中一个长期运行的Web服务时对应用程序的实时部署进行了抽查,这是非常典型的:70个任务在运行,Windows服务流程有关于150个线程,平均CPU使用率30-60%。通常我的意思是CPU使用率通常在40%左右,很少超过80%,但是有大量的任务正在运行,并且流程使用了线程。

2 个答案:

答案 0 :(得分:1)

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

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

如果您想测试这个概念,可以使用实验here,这可能会对您有所帮助。

答案 1 :(得分:1)

注意:我之前从未回答过我自己的问题,所以我希望这是合适的。随意评论或不同意,但看起来这是其他任何人都没有得到答案。

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

解决此问题后,Web服务再次开始及时响应。这让我得出结论,你可以同时运行很多TPL任务(比如我的例子中的数百个),即使他们大量使用Thread Pool工作线程,WCF仍然可以使用Thread Pool的托管I / O线程有效地处理您的Web服务请求。