我们正在使用 NATS 并使用 3 个以上节点的集群。我们有几个生产者和许多消费者。消息大小很小(~100bytes)但是我们的吞吐量有点高。~40k/秒。所有流量都在 2x10gbps 绑定内部网络上。
我很好奇使用更多节点扩展集群是否会有助于集群的吞吐量。我们有一些小的延迟,随着更多消息/秒的写入,它似乎略有增长。
作为次要说明,是否有可以提高吞吐量的提示/技巧?我们目前正在使用 protobufs,但是否可以进行服务器调整?
我们正在使用 NATS 并使用 3 个以上节点的集群。我们有几个生产者和许多消费者。消息大小很小(~100bytes)但是我们的吞吐量有点高。~40k/秒。所有流量都在 2x10gbps 绑定内部网络上。
我很好奇使用更多节点扩展集群是否会有助于集群的吞吐量。我们有一些小的延迟,随着更多消息/秒的写入,它似乎略有增长。
作为次要说明,是否有可以提高吞吐量的提示/技巧?我们目前正在使用 protobufs,但是否可以进行服务器调整?
如果给定主题上有许多匹配的订阅,则吞吐量可能会受到影响。
例如,假设您使用 1 个连接并在foo
. 有 100 个订阅foo
。当服务器收到一条消息时,它将把它传递给所有匹配的订阅。在这种情况下,这意味着 TCP 发送此消息 100 次,无论订阅是否属于同一个连接。
在向订阅者发送消息时,服务器不会读取此连接发布的其他消息。
如果您还在集群中分配订阅负载,则通过添加服务器进行水平扩展可能会有所帮助。在上面的示例中,假设 50 个消费者在一台服务器上,50 个在另一台服务器上,那么接收已发布消息的服务器现在只需发送该消息 50+1 次(本地订阅者为 50 次,路由为 1 次)。然后,另一台服务器将向其本地订阅者发送 50 条消息。
但是,如果存在单个(或没有)匹配订阅,则仅添加服务器不会提高单个连接吞吐量。
提高 pub 吞吐量的另一种方法是使用更多连接。由于服务器对每个连接使用 go 例程(从套接字读取数据然后发送到订阅),因此可以并行化一些工作。
我可以运行 repo 中包含的一些基准测试来获得你可以在你的机器上获得的上限。例如,服务器基准测试通常将数据直接写入套接字,而不是使用 NATS 客户端。这是为了衡量服务器性能,不受客户端实现的任何限制:
go test -v -run=xxx -bench=. ./test
确保查看您发送消息的方式以及它们在订阅回调中的处理方式。你可以做的任何事情来提高性能都会有更大的价值。
希望这可以帮助。