我们有 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%,但是有大量的任务正在运行,并且流程使用了线程。
答案 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服务请求。