为什么 WCF 服务能够处理来自不同进程的调用比来自线程的调用更多

Why WCF service able to process more calls from different processes than from thread

为什么配置了每次调用实例化和多并发的 WCF 服务在 运行 具有不同进程时表现不同,而在从线程调用时表现完全不同?

我有一个应用程序确实通过线程数分发数据并调用(不要认为锁定发生在代码中,将再次测试)WCF 服务。在测试期间注意到分发应用程序中线程数量的增加不会提高 wcf 处理服务的整体性能,平均约为 800 mpm(每分钟处理的消息数)因此吞吐量不会真正改变但是如果你 运行 第二个应用程序然后平均吞吐量增加到 ~1200 mpm。

我做错了什么?我错过了什么?我无法理解这种行为。

更新 #1(回答评论中的问题)

感谢您这么快的回复。 最大连接数在配置中设置为 1000(在 system.net 中是)。 参考这篇文章 wcf Instances and threading 最大调用应该是 16 x 内核数,所以我假设如果在 2 cpu 上调用 ~30 个线程,wcf 服务应该接受大部分这些线程调用?

跟共享内存有关系吗?因为我认为这可能是多线程和进程之间的唯一区别。

现在没有机会用更多 cpu 或单个来测试它。有空就做。

所以我认为要了解此行为,您首先需要了解 WCF 如何使用每次调用实例处理调用。提示在名称中 - Per Call.

任何客户端发出的每次调用都由服务的新实例提供服务(例外情况是重入,但这在您的场景中并不重要)。

因此,为服务行为配置服务并发性 makes no practical difference。无论调用来自单个多线程客户端还是多个客户端,服务的行为都是一样的:每次调用都会创建一个服务实例。

因此,整体系统性能的差异必须是由于客户端的某些原因造成的。如果我不得不大胆猜测,我会说一个客户端比两个客户端慢,因为与 context switching 相关的成本被 运行 中的客户端减轻(通过未识别的机制)两个独立的过程。

如果我是正确的,那么您应该能够通过 运行 多个单线程客户端获得每个线程的最高性能,这是您可以进行的测试。

在此操作实现中,应将以下属性添加到 class。

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)]
public class MyService : IMyService
{
}

您可以在这里阅读更多内容: http://wcftutorial.net/Per-Call-Service.aspx