我正在尝试找到一种最佳解决方案，用于通过 Internet 发送大量小消息（通常每秒约 1000 条，最高可达每秒 10000 条。每条消息最大为 1KB），但可能的延迟最小（想想例如财务数据）。我从基本的双工 WCF 通道开始——这对本地网络非常有用。比我需要将我的合同更改为单向（OperationContractAttribute 并将 IsOneWay 属性设置为 true），否则每条消息都等待确认，因此每条消息的网络延迟计算两次。即使在此之后，我的服务有时仍然无法赶上（在服务器端我只是从队列中读取消息并立即发送，在客户端我只是在接收后将消息排入队列并且不阻塞）。
我想知道发送大量小消息是否会产生一些开销。有没有更好的方法（例如某种基于 TCP 的流式传输）？
Edit1： 根据反馈，我添加了一些技术信息：
我们的服务处于可以并发调用的 Singleton 实例模式（[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)]）。
我们没有配置限制，所以它有默认值（但是只有很少的并发客户端 - 1 到 4）
事实上，我们使用双工通道——客户端调用（注册），然后服务器向客户端发送大量消息。客户端本身执行的调用很少。服务器通过回调通道以同步的方式调用客户端（我们遍历阻塞队列），但是非常非常频繁（那些提到每秒约 1000 条消息，但甚至每秒几千条消息）。
Edit2：解释为什么这与WCF 扩展到大量客户端用户的效果如何？问题：
在我们的场景中，我们实际上有非常少量的客户端（我们甚至只考虑一个客户端），但是大量的消息被连续发送到那个客户端 - 所以它类似于流场景。
我们已经对典型的客户端场景和服务吞吐量进行了测量，发现我们目前在某些情况下无法很好地扩展（对于需要发送大量消息的一天中的短时间的互联网客户端 - 然后那些可能由 WCF 排队，因为我们暂时看到接收时间延迟增加）。
不幸的是，扩展到多个服务器盒对我们来说不是可行的解决方案（一个客户端需要整天连接到一台服务器）。