NATS JetStream多并行消费者场景下发布者性能骤降问题咨询

概述 #

我们使用nats bench CLI工具对NATS JetStream在不同变量下的性能进行基准测试。

我们的业务场景需要10万个并行临时消费者（ephemeral consumer）订阅流。选择JetStream和临时消费者的原因是，我们需要向浏览器应用推送实时数据，且应用需支持消息重放能力，以便在加载前获取所有订阅主题的最新状态。

基准测试后发现，随着并行消费者数量增加，发布者吞吐量急剧下降。

我们运行以下命令测试10KB payload、10万条消息的场景，该命令会创建<sub>个临时消费者和<pub>个并行发布者：

nats bench bar --js --pub <pub> --sub <sub> --size 10000 --msgs 100000 --maxbytes=50GB --no-progress --purge

测试结果 #

以下是不同pub和sub值下的输出，测试实例为AWS EC2 m5.2xlarge（8核CPU，32GB内存）：

pub: 1, sub 1: Publisher Throughput: 19082.0 msgs/sec
pub: 1, sub 10: Publisher Throughput: 8432.67 msgs/secc
pub: 1, sub 100: Publisher Throughput: 1047.33 msgs/sec
pub: 1, sub 1000: Publisher Throughput: 83.33 msgs/sec

测试复现步骤 #

• 安装nats-cli
• 安装nats-server
• 以JetStream模式运行nats server：nats-server -c server.conf --js
• 运行以下nats bench命令：

nats bench bar --js --pub 1 --sub 1 --size 10000 --msgs 100_000 --maxbytes=50GB --no-progress --purge
nats bench bar --js --pub 1 --sub 10 --size 10000 --msgs 100_000 --maxbytes=50GB --no-progress --purge
nats bench bar --js --pub 1 --sub 100 --size 10000 --msgs 10_000 --maxbytes=50GB --no-progress --purge
nats bench bar --js --pub 1 --sub 1000 --size 10000 --msgs 1000 --maxbytes=50GB --no-progress --purge

已尝试方案及观察结果 #

• 采用AWS m5.2xlarge实例搭建3节点和5节点集群进行水平扩展，发布者吞吐量无显著提升，结果类似。
• 垂直扩展至m5.8xlarge（32核CPU，128GB内存），单节点、3节点和5节点配置下均无显著提升，即使有1万个消费者时CPU利用率也仅达25%左右，未充分利用。
• 将nats bench的--consumerbatch和--pubbatch参数从默认100修改为1000，无显著提升。
• 启用--multisubject参数，无显著提升。
• 搭建5节点集群，仅向leader节点发送发布请求，消费者仅连接其余4个非leader节点，无显著提升。
• 在上述所有场景中，数据显示发布者吞吐量与单个消费者的订阅吞吐量匹配。
• 使用NATS core publish替代JetStream publish后性能大幅提升，但需了解该方案的弊端。

预期行为 #

发布者吞吐量不应随并行消费者数量增加而显著下降。

技术问询 #

• JetStream中并行消费者数量增加导致发布者吞吐量骤降是否为预期行为？背后原因是什么？如何提升JetStream发布吞吐量？
• JetStream支持的单流、单服务器最大并行临时消费者数量分别是多少？
• 使用NATS core publish替代JetStream publish有何弊端？据我理解，只要主题属于JetStream流，两种方式都会保留、持久化并复制消息。
• 为何NATS core publish性能不受消费者数量影响，而JetStream publish受影响？
• nats bench工具是否存在限制导致测试结果偏差？

内容的提问来源于stack exchange，提问作者Anish Gupta