ETCD性能测试

最新推荐文章于 2024-09-17 09:32:55 发布

catch that elf

最新推荐文章于 2024-09-17 09:32:55 发布

阅读量5.1k

点赞数 1

分类专栏： Golang 文章标签： etcd 性能测试 etcdkeeper

本文链接：https://blog.csdn.net/zhangxm_qz/article/details/121258656

版权

Golang 专栏收录该内容

20 篇文章 2 订阅

订阅专栏

本文对单节点和三节点Etcd集群进行了读写性能测试。读性能测试显示，单节点和集群在线性读取时均表现出高QPS，而写性能方面，单节点ETCD可达30000QPS，但集群写入超过一定QPS后可能因一致性算法限制导致错误。测试总结表明，Etcd在读写性能上表现优秀，但在高并发写入时需要注意其一致性策略的影响。

摘要由CSDN通过智能技术生成

etcd集群部署参照 etcd部署及实战
etcd自带性能测试工具benchmark，这里使用该工具对etcd集群读写性能进行测试。

环境准备

准备一个单节点etcd服务，一个三节点etcd集群，部署服务器采用 8C 32G的云服务器。
单节点ETCD服务 x.x.x.177:8989
三节点ETCD集群x.x.x…179:8989, x.x.x.179:443, x.x.x.180:443

Benchmark准备

下载benchmark 工具代码，https://github.com/etcd-io/etcd 下的 tools/benchmark目录，main.go 编译成可执行文件并上传到服务器x.x.x.178
可以直接下载编译后的结果使用，点击下载

etcdkeeper安装

下载部署etcdkeeper 用来管理etcd中的数据。etcdkeeper是etcd的界面化管理工具,
下载程序包，etcdkeeper-v0.7.5-linux_x86_64.zip ，下载

unzip etcdkeeper-v0.7.5-linux_x86_64.zip
进入程序目录启动 etcdkeeper 服务
./etcdkeeper -h /x.x.x.180 -p 8989

访问服务器ip及端口：http://x.x.x.180:8989 即可通过界面来访问etcd服务

在这里插入图片描述

读性能测试

etcdkeeper中写入/root/key 的值，然后进行读取测试。
这里分别测试单节点/集群的线性和非线性读的性能，共执行1000000次，命令如下
./Benchmark --endpoints=x.x.x.177:8989 --conns=1000 --clients=100 range /root/key --consistency=l --total=1000000
./Benchmark --endpoints=x.x.x.177:8989 --conns=1000 --clients=100 range /root/key --consistency=s --total=1000000
./Benchmark --endpoints=x.x.x.179:8989,x.x.x.179:443,x.x.x.180:443 --conns=1000 --clients=100 range /root/key --consistency=l --total=1000000
./Benchmark --endpoints=x.x.x.179:8989,x.x.x.179:443,x.x.x.180:443 --conns=1000 --clients=100 range /root/key --consistency=s --total=1000000

测试结果
环境请求数量连接数客户端数量并发方式 QPS 平均时延（ms）
单节点 1000000 1000 100 串行化 77259 1.1
单节点 1000000 1000 100 线性 51717 1.8
集群(3节点) 1000000 1000 100 串行化 95637 0.9
集群(4节点) 1000000 1000 100 线性 57138 1.7

写性能测试

这里分别对单节点和集群进行100000次写入，观察效率和时延，命令如下
./Benchmark --endpoints=1x.x.x.179:8989,x.x.x.179:443,x.x.x.180:443 --conns=1000 --clients=100 put --key-size=10 --sequential-keys --total=100000 --val-size=256
./Benchmark --endpoints=x.x.x.177:8989 --conns=1000 --clients=100 put --key-size=10 --sequential-keys --total=100000 --val-size=256
测试结果
环境请求数量 key大小（字节） value大小（字节）连接数客户端数量 QPS 平均时延（ms）错误数å
单节点 1000000 10 256 1000 100 30447 3.3 0
单节点 1000000 10 256 5000 1000 47108 20 0
单节点 1000000 10 256 10000 1000 46413 20 0
单节点 1000000 10 256 15000 1000 45594 20 0
单节点 1000000 10 256 20000 1000 44011 21 0
单节点 1000000 10 256 20000 1000 44011 21 0
单节点 1000000 10 256 20000 2000 33042 59 0
单节点 1000000 10 256 25000 2000 33042 59 0
集群(3节点) 200000 10 256 1000 100 4438 22 0
集群(3节点) 200000 10 256 1000 200 7309 27 0
集群(3节点) 200000 10 256 1000 300 9165 32 33722
集群(3节点) 200000 10 256 1000 500 12159 37 99362
集群(3节点) 200000 10 256 1000 1000 17352 46 65582
集群(3节点) 200000 10 256 3000 1000 19550 46 44383
集群(3节点) 200000 10 256 5000 1000 17216 52 65960
集群(3节点) 200000 10 256 10000 1000 18118 42 56263
集群(3节点) 200000 10 256 15000 1000 16777 48 72945
集群(3节点) 200000 10 256 20000 1000 19299 43 77888

测试总结

Etcd在服务器上读性能很优秀，单节点和集群线性读性能均在50000QPS以上，非线性读性能在70000QPS以上
单节点ETCD写性能优秀，能达到30000QPS，在不同时间点甚至达到45000左右。
但是由于一致性算法的制约，集群写性能超过7000QPS。就有可能报错 etcdserver: too many requests。
经过百度得知，该错误是因为提交到etcd Raft模块的请求会做一些限流判断，如果 Raft 模块已提交的索引（committed index）比已应用到状态机的索引（applied index）多于 5000，就返回 “etcdserver: too many requests” 给 client。