DragonFly集群在Memtier基准测试中性能下降的原因咨询

1. WSL网络栈的跨节点通信瓶颈 #

WSL2的虚拟网络架构依赖Hyper-V虚拟网卡转发，本身比原生Linux有更高的网络延迟。搭建多节点集群后，分片key的跨节点访问会产生额外的路由转发开销，这种延迟会被memtier_benchmark的多线程高并发放大——单节点测试无需跨节点通信，性能不受影响，但集群场景下延迟累积导致整体性能暴跌。

验证方法：

• 用iperf3测试集群节点间的带宽和延迟，对比原生Linux环境下的结果；
• 将集群部署到原生Linux服务器上重新运行相同测试，看性能是否恢复到预期水平。

2. memtier_benchmark对DragonFly集群路由的适配不足 #

DragonFly集群兼容Redis Cluster协议，但memtier_benchmark的集群模式逻辑可能仅针对Redis Cluster做了优化，未适配DragonFly的分片路由细节。如果测试时未开启memtier的集群模式（未加--cluster-mode参数），所有请求会直接发送到单个节点，导致大量请求需要通过MOVED/ASK重定向到目标节点，每个重定向都会增加一次网络往返，大幅降低吞吐量。而redis-benchmark对重定向的处理更高效，所以集群测试性能有提升。

验证方法：

• 运行测试时添加--cluster-mode参数（确认memtier版本支持），对比性能变化；
• 用tcpdump抓包，查看是否存在大量MOVED响应包；
• 对比Redis Cluster环境下相同memtier命令的性能表现，判断是否是DragonFly特有的兼容问题。

3. 连接数与线程调度的冲突 #

你使用的参数是-t 4 -c 50，即4线程×50连接=200个并发连接。在WSL的CPU调度限制下，DragonFly集群节点的线程模型处理跨节点连接时，可能出现严重的线程竞争——单节点的DragonFly采用了优化过的单线程+协程模型，而集群模式下多节点的线程调度开销叠加WSL的性能瓶颈，导致整体吞吐量下降。

验证方法：

• 降低并发参数（比如-t 2 -c 20）重新测试，看性能是否有所回升；
• 执行redis-cli -p <port> INFO stats查看connected_clients、thread_running等指标，确认是否存在线程阻塞或连接堆积。

4. 数据分片负载不均衡 #

如果测试用的key分布不均匀（比如memtier默认的key生成策略导致大量key集中在某个分片），会使对应主节点负载过高，其他节点空闲，整体性能被拖垮。而单节点测试不存在分片问题，所以性能稳定。

验证方法：

• 执行redis-cli -p <port> CLUSTER SLOTS查看分片分布，确认每个分片的节点负载；
• 调整memtier的key生成策略为--key-pattern=P:P（均匀分布key到所有分片），重新测试对比性能。

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