哪种 WCF 绑定性能最高？
我必须在 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();
}
}
}
上面的代码是实际代码的简化版本。
I have to get the maximum throughput performance in my WCF service. In one of my tests the service below got only 50k data items per minute using NetTcpBinding. Would a disconnected binding like NetMsmqBinding improve this performance?
Service and client uses WCF and run in the same machine.
[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();
}
}
}
The code above is a simplified version of the actual code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Msmq 可能比 TcpBinding 慢。
如果您在同一台计算机上运行，则绝对应该使用 NetNamedPipeBinding (IPC)，这是最快的可用绑定。
您还应该检查如何序列化数据。 Protocol Buffer 序列化比默认的 WCF 二进制序列化要快得多（也更精简）（但需要进行一些调整）。
Msmq is likely to be slower than TcpBinding.
If you're running on the same machine, you definitely should use NetNamedPipeBinding (IPC) which is the fastest binding available.
You should also check how you're serializing your data. Protocol Buffer serialization is a lot faster (and leaner) than default WCF binary serialization (but requires a little bit of tweaking).
对于单独的单个调用，还是对于大量的数千个调用，速度更快？
NetMsmq 使用 MSMQ 消息队列 - 您将消息放入由 MSMQ 处理的队列中，服务最终将从该队列中获取消息并对其进行处理。您不会得到即时反馈，这些消息只是单向的。
另一方面，NetTcp 与 http 类似，只是速度更快。您向服务发送请求并立即收到响应（如果一切顺利）。本身不涉及消息队列，您的消息是请求/回复。
所以我不认为你真的可以比较这两个绑定。它们具有完全不同的目的：
如果您想查找邮政编码并获取该位置的经度/纬度，您肯定需要一个请求/响应机制 -->使用 netTcp
如果你想存入请求，例如打印文档，或重新组织数据库，或类似的东西 - 最终需要处理的东西，但你不希望立即返回响应（但是您可以稍后检查消息是否已被正确处理），然后
希望这能让事情变得更清晰 - 我不认为这两个确实适用于同一组操作，因此您很可能不必直接在这两者之间进行选择:)
Faster for a single call in isolation, or for a flood of thousands of calls?
NetMsmq uses MSMQ message queueing - you're putting your message into a queue handled by MSMQ, and the service will get it from that queue eventually and work on it. You don't get instant feedback, the messages are one-way only.
NetTcp on the other hand is like http - only faster. You send a request to the service and get back a response (if all goes well) right away. No message queueing per se involved, your messages are request/reply.
So I don't think you can compare the two bindings, really. They serve totally different purposes:
if you want to e.g. look up a zip code and get back the longitude/latitude of that location, you definitely want a request/response mechanism --> use netTcp
if you want to deposit requests to e.g. print a document, or reorganize a database, or something of that nature - something that needs to be tended to eventually, but you don't expect back a response right away (but you can later check if the message has been handled properly), then use a message queueing system
Hope that makes things a bit clearer - I don't think these two really are geared towards the same set of operations, so you most likely won't ever have to choose between those two directly :)
如果服务和客户端在同一台机器上运行，我会完全避免使用网络，而采用 IPC 机制（例如命名管道）。网络流量会产生大量开销，可以通过使用 IPC 机制来避免。
If the service and client run on the same machine I would avoid the network altogether in favor of an IPC mechanism such as named pipes. Network traffic incurs a lot of overhead which can be avoided by using an IPC mechanism.
您是否有理由相信交通是导致交易速度减慢的原因？剖析告诉了你什么？现在该服务被设置为单线程，并且还具有多个对“Get”的调用，彼此锁定。
如何调用/使用该服务？让它成为多线程会有帮助吗？使用更复杂的锁（例如 ReaderWriterLock）怎么样？它允许同时发生对 Get 的多个调用，但仍然阻止“Add”？
编辑：我知道这是一个简化的情况，但实际的服务是否会从相同的考虑中受益？
Do you have reason to believe that the transport is what is slowing down the transaction rate? What has profiling told you? Right now this service is set to be single threaded, and also has multiple calls to "Get" lock each other out.
How is this service called/used? Would it help to make it multi-threaded? What about using a more sophisticated lock like a ReaderWriterLock which allows multiple calls to Get to occur at the same time, but still block on "Add"?
Edit: I know this is a simplified situation, but would the actual service benifit from the same considerations?