以前的几篇blog,给你们分享的都是kingshard(https://github.com/flike/king... )的架构与设计。其实不少人对kingshard的性能也很是关心。最近热心的网友bigpyer对kingshard作了详细的性能测试。在此分享一下。mysql
类别 | 名称 |
---|---|
OS | 云主机 Ubuntu 14.04 LTS |
CPU | Common KVM CPU @ 2.40GHz *4 |
RAM | 8GB |
DISK | 500GB |
kingshard | master分支 |
Mysql | v5.6.25 |
Sysbench | v0.5 |
利用上述配置的4台服务器搭建了一个kingshard性能测试环境:git
四台服务器处在同一个网段中。具体的拓扑图以下所示:github
有关kingshard系统安装与配置,请参考文档安装kingshard。
有关sysbench v0.5的安装与命令选项,请参考sysbench。sql
执行下面的命令准备测试数据后端
time sysbench --test=/data/home/test_user/software/sysbench/sysbench/tests/db/oltp.lua \ --mysql-host=host \ --mysql-port=9696 \ --mysql-user=kingshard \ --mysql-password=kingshard \ --mysql-db=kingshard \ --oltp-tables-count=1 \ --oltp-table-size=1000000 \ --num-threads=50 \ --max-requests=1000000 \ --report-interval=1 \ prepare
上述命令会建立表sbtest1,数据量为100w,建表语句以下:服务器
CREATE TABLE `sbtest1` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', KEY `xid` (`id`), KEY `k_1` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8 MAX_ROWS=1000000;
利用sysbench测试经过kingshard转发SQL请求和直连DB发送SQL请求这两种状况下,kingshard和Mysql系统的两项数据指标:QPS和每条SQL请求平均处理时间。
经过sysbench发送四类SQL请求:select、update、insert和delete,场景分别为只读、读写4比1和只写。网络
经过修改host、port执行下面的命令分别测试kingshard转发SQL或直连DB:架构
time sysbench --test=/data/home/test_user/software/sysbench/sysbench/tests/db/select.lua \ --mysql-host=host \ --mysql-port=9696 \ --mysql-user=kingshard \ --mysql-password=kingshard \ --mysql-db=kingshard \ --oltp-tables-count=1 \ --oltp-table-size=1000000 \ --num-threads=16 \ --max-requests=1000000 \ --report-interval=1 \ --max-time=20 \ run
利用sysbench测试了并发线程个数不一样的状况下,分别执行最大请求次数为100w的 select操做,经过修改--num-threads能够得到不一样并发线程数。
测试链接 kingshard 和直连 DB 这两种状况下的 QPS(QPS越大,系统性能越好),
测试链接 kingshard 和直连 DB 这两种状况下的 执行sql平均时延(时延越小,系统性能越好),
每组数据重复测试三次后取平均值,具体数据对好比下表所示:并发
上表对应的QPS折线图以下所示:高并发
上表对应的时延折线图以下所示:
经过修改host、port执行下面的命令分别测试kingshard转发SQL或直连DB:
ysbench --test=/data/home/test_user/software/sysbench/sysbench/tests/db/oltp.lua \ --mysql-host=host \ --mysql-port=3306 \ --mysql-user=kingshard \ --mysql-password=ks \ --mysql-db=kingshard \ --oltp-tables-count=1 \ --oltp-table-size=1000000 \ --num-threads=16 \ --max-requests=1000000 \ --report-interval=1 \ --max-time=20 \ run
利用sysbench测试了并发线程个数不一样的状况下,分别执行最大请求次数为100w的 select、update、insert、delete等混合操做,经过修改--num-threads能够得到不一样并发线程数。
测试链接 kingshard 和直连 DB 这两种状况下的 QPS(QPS越大,系统性能越好),
测试链接 kingshard 和直连 DB 这两种状况下的 执行sql平均时延(时延越小,系统性能越好),
每组数据重复测试三次后取平均值,具体数据对好比下表所示:
上表对应的QPS折线图以下所示:
上表对应的时延折线图以下所示:
经过修改host、port执行下面的命令分别测试kingshard转发SQL或直连DB:
time sysbench --test=/data/home/test_user/software/sysbench/sysbench/tests/db/insert.lua \ --mysql-host=host \ --mysql-port=3306 \ --mysql-user=kingshard \ --mysql-password=ks \ --mysql-db=kingshard \ --oltp-tables-count=1 \ --oltp-table-size=1000000 \ --num-threads=16 \ --max-requests=1000000 \ --report-interval=1 \ --max-time=20 \ run
利用sysbench测试了并发线程个数不一样的状况下,分别执行最大请求次数为100w的insert操做,经过修改--num-threads能够得到不一样并发线程数。
测试链接 kingshard 和直连 DB 这两种状况下的 QPS(QPS越大,系统性能越好),
测试链接 kingshard 和直连 DB 这两种状况下的 执行sql平均时延(时延越小,系统性能越好),
每组数据重复测试三次后取平均值,具体数据对好比下表所示:
上表对应的QPS折线图以下所示:
上表对应的时延折线图以下所示:
**从QPS折线图能够看出,当sysbench的并发测试线程较少时,链接kingshard和直连DB的QPS差距较大。
这主要是由于当sysbench并发线程少时,kingshard的性能没有获得充分的发挥,
sysbench只有不多的线程向kingshard发送请求,此时网络延迟对QPS的影响是最主要的。**
**当sysbench的并发测试线程较大时,此时kingshard的性能就获得了充分的发挥,
QPS的对比是链接kingshard与直连DB性能对比的真实的反应,网络延迟对QPS的影响做用就显得很小了。**
**从以上几个表个的比例数据来看,经过kingshard转发select请求时的QPS是直连DB时80%左右,
而update和insert请求对应的QPS则更高一些,至关于直连DB时的85%左右,甚至在并发更高的状况下直连mysql的性能低于经过kingshards转发的性能。
由此看来利用kingshard转发SQL请求带来的性能降低虽有降低,但彻底能够接受,甚至高并发场景下kingshard的性能优于直连DB的性能。这也是得益于kingshard在高并发的时候,充分利用了链接池的做用,下降了高并发带来的竞争消耗。**
sysbench并发线程高于512的数据并无给出,由于直连DB已经不能正常完成测试,可是kingshard能够完成。
max_conns_limit 是 kingshard 初始化时建立的与后端mysql长链接个数,这个值设置的不一样对 kingshard 性能也有比较明显的影响。
咱们猜想max_conns_limit除了与kingshard所在主机CPU核心数有关外还与后端mysql能接纳的链接数有关。
咱们分别测试将 max_conns_limit 设置为1六、3二、6四、12八、25六、512时,kingshard转发select,update和insert三类操做请求时的 QPS,
SQL的混合状况为读写4比1,且sysbench的不一样sql分别处于不一样的事务中,具体对比结果以下所述:
上数测试对应的QPS折线图以下所示:
从kingshard处理三类SQL操做的QPS对比来看,将max_conns_limit参数设置为128左右较为合理, 高于128后经过提升max_conns_limit值并无显著效果。
max_conns_limit参数值与kingshard所在主机核心数并无必然的联系,与后端mysql主机可承受链接数关系密切。
本文主要测试了经过kingshard转发SQL请求与直连DB发送SQL请求这两种情形下的性能差距,和max_conns_limit值对kingshard的性能影响。
ks的读写性能平都可以达到原生mysql性能的80%,必定条件下能够达到90%,随着并发数的增长甚至能超越mysql自己。
ks能够对mysql造成保护,增长了ks后,db层对外表现出能够接收更高的并发数,且执行时间长短不一样的sql使用各自的资源,造成了资源隔离,mysql不会出现性能毛刺。
综合以上测试结果来看,kingshard性能表现较为优秀,并无明显的性能降低。同时在测试中发现kingshard系统属于CPU密集型任务,相对于磁盘IO和内存占用率而言,kingshard对CPU消耗显得最为明显,因此建议在部署kingshard的时候须要优先考虑服务器的CPU性能。
欢迎关注后端技术快讯公众号,有关kingshard的最新消息与后端架构设计类的文章,都会在这个公众号分享。