我需要优化WCF服务......这是一件非常复杂的事情。这次我的问题与任务有关（Task Parallel Library，.NET 4.0）。发生的事情是我在调用服务时使用Task.Factory.StartNew）启动多个任务，然后等待它们完成：
Task.WaitAll(task1, task2, task3, task4, task5, task6);
好吧......我看到的，不喜欢的是，在第一次通话时（有时前2-3次通话，如果一个接一个地快速进行），最后的任务比其他任务开始得晚得多（我正在看一个在其他人开始后0.5秒开始的情况）。我试着打电话
ThreadPool.SetMinThreads(12*Environment.ProcessorCount, 20);
在我的服务开始时，但它似乎没有帮助。
这些任务都与数据库有关：我正在从多个数据库中读取数据，并且需要花费尽可能少的时间。
知道为什么上一个任务花了这么长时间？我有什么可以做的吗？
或者，我应该直接使用线程池吗？事实上，在我看到的一个案例中，一个任务在最后一个任务开始之前已经结束 - 如果我重新使用该线程而不是等待创建新线程，我将节省0.2秒。但是，我不能确定 任务总是如此快地结束，所以我不能将两个请求放在同一个任务中。
[编辑]操作系统是Windows Server 2003，因此不应该有连接限制。此外，它托管在IIS中 - 我不知道我是应该创建常规线程还是使用线程池 - 这是首选版本？
[编辑]我也尝试使用Task.Factory.StartNew(action, TaskCreationOptions.LongRunning); - 它没有帮助，最后一项任务仍然比其他任务开始的时间晚了（大约半秒钟后）。
[编辑] MSDN 1说：
线程池有内置延迟 （.NET Framework中的半秒钟 版本2.0）在开始新的空闲之前 线程。如果你的申请 定期启动a中的许多任务 短时间内，小幅增加了 空闲线程数可以产生一个 吞吐量显着增加。 也设置空闲线程数 高消耗系统资源 不必要。
但是，正如我所说，我已经在调用SetMinThreads而且没有帮助。
答案 0 :(得分：7)
使用（.Net 4.0）Task-object时，我自己遇到了线程启动延迟的问题。所以对于时间紧迫的东西，我现在使用专用线程（......再次，因为这是我在.Net 4.0之前所做的。）
线程池的目的是避免启动和停止线程的操作系统成本。线程只是被重用。这是在例如互联网服务器中发现的常见模型。优点是他们可以更快地做出反应。
我编写了许多应用程序，通过让专用线程从任务队列中获取任务来实现我自己的线程池。但请注意，这通常需要锁定，这可能会导致延迟/瓶颈。这取决于你的设计;这些任务很小，然后就会有很多锁定，交换一些CPU可能会更快锁定：http://www.boyet.com/Articles/LockfreeStack.html
SmartThreadPool是.Net线程池的替换/扩展。正如您在此链接中所看到的，它有一个很好的GUI来进行一些测试：http://www.codeproject.com/KB/threads/smartthreadpool.aspx
最终它取决于您的需求，但为了获得高性能，我建议您实现自己的线程池。如果你经历了很多线程空闲，那么增加线程数可能是有益的（超出推荐的cpucount * 2）。这实际上是HyperThreading在CPU内部的工作方式 - 在执行其他操作时使用“空闲”时间。
请注意.Net具有每个进程25个线程的内置限制（即，对于您同时收到的所有WCF调用）。此限制是独立的，并且会覆盖ThreadPool设置。它可以增加，但需要一些魔法：http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=201
答案 1 :(得分：3)
根据我先前的问题（是的，应该是反对原始消息的Q - 道歉）：
为什么您觉得为机器中的每个处理器核心创建12个线程会以某种方式加快服务器创建工作线程的能力？你所做的只是减慢你的服务器速度！
根据MSDN做
根据MSDN文档：“您可以使用SetMinThreads方法来增加最小线程数。但是，不必要地增加这些值会导致性能问题。如果太多任务从同一个开始时间，所有这些都可能看起来很慢。在大多数情况下，线程池将通过自己的分配线程的算法表现更好。将最小值减少到小于处理器数量也会损害性能。“。
这样的问题通常是由于在共享资源上遇到限制或争用而引起的。
在您的情况下，我猜测您的上一个任务在等待与DB服务器的连接可用或数据库响应时是否阻塞。请记住 - 如果您的调用启动了5-6个其他任务，那么您的计算机将不得不创建并打开大量数据库连接，并且可能会为数据库提供大量工作。如果您的WCF服务器和/或您的数据库服务器是冷的，那么在填充机器的缓存等之前，您的前几次调用将会变慢。
您是否尝试使用秒表添加一些跟踪/日志记录来计算任务连接到数据库服务器然后执行其操作所需的时间？
您可能会发现减少启动的并发任务数实际上会加快速度。尝试一次产生3个任务，等待它们完成，然后产生接下来的3个任务。
答案 2 :(得分：3)
当您致电Task.Factory.StartNew时，它会使用TaskScheduler将这些任务映射到实际工作项中。
在您的情况下，当操作系统为工作项旋转新线程时，听起来您的任务之一偶尔会延迟。您可以构建一个custom TaskScheduler，它已经包含处于等待状态的六个线程，并明确地将它们用于这六个任务。这样您就可以完全控制这些初始任务的创建和启动方式。
话虽如此，我怀疑此处还有其他内容......你提到使用TaskCreationOptions.LongRunning表示同样的行为。这表明存在一些其他因素导致这种半秒延迟。我怀疑这是因为TaskCreationOptions.LongRunning的性质 - 当使用默认的TaskScheduler（LongRunning是TaskScheduler类使用的提示）时，启动{{1}的任务实际上为该Task创建了一个全新的（非ThreadPool）线程。如果使用TaskCreationOptions.LongRunning创建6个任务，则演示相同的行为，您几乎可以保证问题不是默认的TaskScheduler，因为这将总是手动启动6个线程。
我建议您通过性能分析器运行代码，可能还需要VS 2010中的Concurrency Visualizer。这可以帮助您准确确定导致半秒延迟的原因。
答案 3 :(得分：1)
什么是操作系统？如果您没有运行Windows的服务器版本，则存在连接限制。由于连接限制，您的许多线程可能正在被序列化。
另外，我还没有使用任务并行库，但我的经验有限，新线程在网络环境中制作起来很便宜。
答案 4 :(得分：1)
这些文章可能会解释您遇到的问题： http://blogs.msdn.com/b/wenlong/archive/2010/02/11/why-are-wcf-responses-slow-and-setminthreads-does-not-work.aspx
看到你正在使用.Net 4，第一篇文章可能不适用，但正如第二篇文章所指出的，ThreadPool在15秒后终止了空闲线程，这可能解释了你所遇到的问题并提供了一个简单的（虽然有点hacky）解决它的方法。你是否应该直接使用ThreadPool不会有任何区别，因为我怀疑任务库无论如何都在为你使用它。
我们一直使用的一个第三方库可能会对您有所帮助 - Smart Thread Pool。您仍然可以获得使用任务库的相同好处，因为您可以从线程获取返回值并从中获取任何异常信息。
此外，您可以实例化线程池，以便当您有多个位置时每个需要一个线程池（以便低优先级进程不会开始进入某个高优先级进程的配额）并且哦，是的，您可以设置优先级池中的线程也不能用标准的ThreadPool做，其中所有线程都是后台线程。
您可以在codeplex页面上找到大量信息，我还有一篇帖子突出了一些主要区别： http://theburningmonk.com/2010/03/threading-introducing-smartthreadpool/
请注意，对于像您提到的那些可能需要一些时间才能返回的任务，您可能不应该使用线程池。建议我们应该避免将线程池用于任何类似的阻塞任务，因为它占用了框架类所有类型的东西所使用的线程池，比如处理定时器事件等等。（更不用说处理传入的WCF了）要求！）。我觉得我在这里发垃圾邮件，但这里有一些关于使用线程池和底部一些有用链接的信息：
http://theburningmonk.com/2010/03/threading-using-the-threadpool-vs-creating-your-own-threads/
好吧，希望这有帮助！