京公网安备11010502063487号ZooKeeper 能扛多少请求?延迟随并发怎么变?这篇用不同数量的并发客户端(每个客户端一个请求接一个请求)压单机与 3 节点集群,画出吞吐与延迟的变化。
[单机]
并发客户端 写 ops/s 写 p50 ms 写 p99 ms 读 ops/s 读 p50 ms 读 p99 ms
1 330 3.01 5.03 7187 0.14 0.19
4 733 5.87 7.31 5090 0.76 1.40
16 3298 4.87 7.40 4764 3.25 6.21
64 5130 12.06 21.09 4687 13.19 24.55每个客户端都是一个线程、一个独立的 kazoo 连接,同步调用(上一个请求返回才发下一个)。
[3 节点]
并发客户端 写 ops/s 写 p50 ms 写 p99 ms 读 ops/s 读 p50 ms 读 p99 ms
1 187 5.09 9.34 6647 0.15 0.21
4 471 8.15 12.75 4884 0.79 1.44
16 2076 7.57 11.96 4572 3.38 6.56
64 4306 14.41 24.04 4573 13.55 25.40客户端连接均匀分布在 3 个节点上;写请求仍然由 leader 排序。
客户端和服务端在同一台机器上抢 CPU;客户端是 Python,读吞吐很早就被 GIL 限制了;磁盘是本机 SSD。这些数字只用来看曲线的形状(吞吐随并发上升、延迟随并发上升、集群写比单机慢),不要当作容量规划的依据——需要用真实的压测工具和真实的硬件重测。