任务并行库如何在终端服务器或 Web 应用程序中扩展？
据我所知，当我执行 Parallel.For 和类似构造之类的东西时，TPL 使用工作窃取队列来执行其任务。
如果我理解正确的话，该构造将启动许多任务，每个任务将开始处理项目。如果其中一个任务完成了分配给他们的物品，它将开始从其他尚未完成的任务中窃取物品。这解决了以下问题：项目 1-100 的处理成本较低，而项目 101-200 的处理成本较高，并且两个任务之一将处于闲置状态，直到另一个任务完成。 （我知道这是一个简化的解释。）
但是，这将如何在终端服务器或 Web 应用程序中扩展（假设我们在将在 Web 应用程序中运行的代码中使用 TPL）？我们是否可以仅仅因为有 N 个并行运行的应用程序实例而冒使 CPU 充满任务的风险？
我应该阅读有关该主题的任何信息吗？我还没有发现任何特别的东西，但这并不意味着没有。
I understand that the TPL uses work-stealing queues for its tasks when I execute things like Parallel.For and similar constructs.
If I understand this correctly, the construct will spin up a number of tasks, where each will start processing items. If one of the tasks complete their allotted items, it will start stealing items from the other tasks which hasn't yet completed theirs. This solves the problem where items 1-100 are cheap to process and items 101-200 are costly, and one of the two tasks would just sit idle until the other completed. (I know this is a simplified exaplanation.)
However, how will this scale on a terminal server or in a web application (assuming we use TPL in code that would run in the web app)? Can we risk saturating the CPUs with tasks just because there are N instances of our application running side by side?
Is there any information on this topic that I should read? I've yet to find anything in particular, but that doesn't mean there is none.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您也许能够使用 TPL 通过迁移到异步模型来改进 I/O 绑定操作。您还可以通过在低负载情况下更多地利用 Web 服务器上可用的未使用处理器容量来改善请求延迟。您需要仔细考虑这一点，因为在高负载下，处理器已经 100% 使用，增加更多并行性会降低服务器的吞吐量。
并行扩展团队博客对此进行了讨论：
使用并行扩展ASP.NET 应用程序中的 .NET 4
我怀疑同样的论点也适用于终端服务器应用程序。
You might be able to use the TPL to improve I/O bound operations by moving to an asynchronous model. You might also be able to improve request latency by making more use of the available unused processor capacity on a web server in low load situations. You want to think about this pretty carefully as under high loads where the processors are already 100% utilized adding more parallelism will reduce throughput on the server.
This is discussed on the Parallel Extensions Team Blog:
Using Parallel Extensions for .NET 4 in ASP.NET apps
I suspect that the same argument applies to Terminal Server applications also.