WCF ConcurrencyMode.Multiple Connection 最佳实践和缓存答案

【问题标题】：WCF ConcurrencyMode.Multiple Connection best practices and CachingWCF ConcurrencyMode.Multiple Connection 最佳实践和缓存
【发布时间】：2009-10-22 20:15:09
【问题描述】：

我有一个具有以下设置的 WCF 服务：

NetNamedPipeBinding
ConcurrencyMode.Multiple
InstanceContextMode.Single

现在我有一个以多线程方式访问此 WCF 服务的客户端。

据我了解，我必须为每个线程打开一个到服务的新连接，以避免线程相互阻塞。

在这种情况下，Open() 调用的成本是多少（服务在同一台计算机上）？
我应该缓存/池化我的客户端类吗？（派生自 ClientBase）还是 WCF 是否为类似于 SQLConnection Pooling 的连接提供透明池？

【问题讨论】：

对于这样的场景，NetNamedPipe 机器上的通信，我不认为 ConcurrencyMode.Multiple 增加的复杂性是一个好处。这只会使您的服务代码更加复杂和容易出错......与在客户端代理创建中节省的几纳秒相比，我不知道这是否值得麻烦和可能的维护麻烦......跨度>
如果没有多重它就不能作为多线程工作，这意味着客户端中的多线程将毫无意义，因为它会相互等待。这不是一个毫秒的调用，它需要几秒钟。还是我错过了什么。

标签： .net wcf performance multithreading caching

【解决方案1】：

不幸的是，WCF 不共享客户端连接。我发现 Open() 相对较慢，并且构建了我自己的池机制，保持客户端和服务器之间的少量持久连接处于打开状态。

对此的一个常见问题是，即使客户端和服务器之间发生了像超时这样简单的事情（或抛出任何类型的 CommunicationException），客户端实例也会进入故障状态并变得不可用。此时您必须销毁并用新实例替换它。

【讨论】：

啊！这太垃圾了。我实际上已经建立了一个缓存系统，但我只是不喜欢额外复杂的想法。感谢您的澄清 +1。
我怀疑 Open() 调用在具有 NetNamedPipe 绑定的“仅机器上”调用场景中速度很慢。是的，使用具有大量 WS-* 功能开销的 wsHttpBinding（默认值）可能会很慢 - 但命名管道非常高效，并且仅在机器上，几乎没有安全性 - 这应该没有问题。跨度>
即使使用 NetNamedPipe，开销也超出了我的承受能力。试一试，认真的。在我的笔记本电脑上，我看到实例时间范围从 150 毫秒到 350 毫秒。最后，我将一个 pub/sub 放在一个有一群客户的调度员面前，并看到了相当壮观的表现。

【解决方案2】：

James Alexander 的答案是正确的（您必须自己池连接），但我想我会发布 a link to a blog entry 讨论在 ClientBase 之上添加连接池的实现。 Here's the follow up post 他详细介绍并提供了下载代码的链接。

【讨论】：

好东西，尤其是基准测试。一些代码怎么样？ :) 我已经添加了一些缓存，但你的实现看起来很整洁，偷看一下会很好:)
这篇博文实际上不是我的（不想盗用功劳！）。我只是知道它，因为我以前研究过这个主题。我应该给你另一个链接到他的帖子，他实际上提供了更多的细节和代码。我将编辑我的条目。
操作！我知道我以为那是你的博客，无论如何绝对是证明这一点的好链接。