哪种 WCF 绑定性能最高？答案

【问题标题】：What WCF binding is most performant?哪种 WCF 绑定性能最高？
【发布时间】：2009-12-02 17:01:38
【问题描述】：

我必须在我的 WCF 服务中获得最大的吞吐量性能。在我的一项测试中，以下服务使用 NetTcpBinding 每分钟仅获得 50k 数据项。像 NetMsmqBinding 这样断开连接的绑定会提高这种性能吗？

服务和客户端使用 WCF 并在同一台机器上运行。

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,
    ConcurrencyMode = ConcurrencyMode.Multiple)]
public class Storage : IStorage
{
    protected List<int> _data = new List<int>();

    public void Insert(int[] data)
    {
        lock (_data)
        {
            _data.AddRange(data);
        }
    }

    public int[] Get()
    {
        lock (_data)
        {
            return _data.ToArray();
        }
    }
}

上面的代码是实际代码的简化版本。

【问题讨论】：

有关如何选择 WCF 绑定的流程图，请参阅 stackoverflow.com/questions/1613586/…。它没有直接解决性能问题，但其他查看此问题的人可能会发现它很有帮助。

标签： .net wcf performance nettcpbinding netmsmqbinding

【解决方案1】：

Msmq 可能比 TcpBinding 慢。

如果您在同一台机器上运行，则绝对应该使用 NetNamedPipeBinding (IPC)，这是可用的最快绑定。

您还应该检查您是如何序列化数据的。 Protocol Buffer 序列化比默认的 WCF 二进制序列化要快得多（也更精简）（但需要稍作调整）。

【讨论】：

是的。这是具有很好的 WCF 支持的两个实现之一。我听说那个库的创建者在这里并不是一个完全未知的人。
我使用了它，但奇怪的是它并没有提高我的服务性能。
你是如何测试它的？你有很多客户还是一个线程中有一个？您也可能会最大化 CPU 使用率。 NamedPipeBinding 在通信方面提供了最佳性能，但如果您在服务或客户端代码中遇到性能障碍，您也必须解决这些问题。

【解决方案2】：

一个单独的呼叫更快，还是成千上万的呼叫泛滥？

NetMsmq 使用 MSMQ 消息队列 - 您将消息放入由 MSMQ 处理的队列中，服务最终会从该队列中获取并处理它。您不会得到即时反馈，消息是单向的。

另一方面，NetTcp 就像 http - 只是更快。您向服务发送请求并立即得到响应（如果一切顺利）。本身不涉及消息队列，您的消息是请求/回复。

所以我认为你不能比较这两个绑定，真的。它们的用途完全不同：

如果你想查找邮政编码并取回该位置的经度/纬度，您肯定需要请求/响应机制 --> 使用 netTcp
如果您想将请求存入例如打印文档，或重组数据库，或类似性质的东西 - 最终需要处理的东西，但您不希望立即得到回复（但您可以稍后检查消息是否已正确处理），然后使用消息队列系统

希望这能让事情变得更清楚一些 - 我认为这两者并不真正适用于同一组操作，因此您很可能不必直接在这两者之间进行选择 :)

【讨论】：

如果你查看我的代码，如果我告诉你每个客户端只使用其中一种操作（一个客户端插入，另一个客户端获取），我想我们会同意 MSMQ 是合适的为我服务。问题是我没用过，也不知道性能好不好。
好吧 - 如果你想“获取”某些东西，你必须在 MSMQ 上向服务发送一个“获取”请求。但是你如何取回数据？由于 MSMQ 始终是单向的........您几乎必须打开另一个（响应）队列，服务将响应放入该队列，并且客户端需要从那里获取数据。不，我不认为，MSMQ 通常是 GET 操作的好主意。
所以如果我理解你的话，我将不得不忽略此服务中的此 GET 方法，并将我的一个客户端转换为接收数据的服务，以便使用 MSMQ？

【解决方案3】：

如果服务和客户端在同一台机器上运行，我会完全避开网络，转而支持 IPC 机制，例如命名管道。网络流量会产生大量开销，这可以通过使用 IPC 机制来避免。

【讨论】：

+1 用于命名管道。耻辱 WCF 4.0 也不得不放弃 localProcessBinding :(

【解决方案4】：

您是否有理由相信是运输导致交易速度变慢？分析告诉了你什么？现在这个服务被设置为单线程的，并且有多个“Get”调用相互锁定。

如何调用/使用此服务？使它成为多线程有帮助吗？如果使用更复杂的锁，如 ReaderWriterLock，它允许同时发生多个 Get 调用，但仍阻止“添加”？

编辑：我知道这是一种简化的情况，但实际服务是否会从相同的考虑中受益？

【讨论】：

是的，我认为实际服务也会受益于高级锁。