MyCAT-1.4-RC基准测试
2016-07-17 14:22
197 查看
文章转载自:http://blog.itpub.net/29510932/viewspace-1726924
测试环境采用虚拟机的方式进行,虚拟机的配置如下:
主库:
CPU:Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz,逻辑核心8个
内存:32GB
硬盘:250G
从库:
CPU:Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz,逻辑核心8个
内存:32GB
硬盘:250G
MyCAT服务器:
CPU:Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz,逻辑核心4个
内存:8GB
硬盘:250G
测试方法最终以Sysbench为准,测试项目分为MySQL单库与MyCAT集群,集群中已经使用范围分区策略对所有测试用表进行了分区,并且进行了读写分离,写操作只在主库,读操作只在从库。
具体测试项目及结果如下表
对勾为测试通过,叉号为测试不通过,是否通过以最终响应时间为标准,平均响应时间超过500ms则认为测试不通过。按照并发线程数依次列出测试结果。512线程并发由于MyCAT服务器性能成为瓶颈,放弃对比测试。
测试结果预期:
由于MyCAT-MySQL集群本身的功能还没有全部实现,因此测试用脚本采用一些特殊处理,具体内容见附录-测试内容备注。
由于使用了严格的读写分离,和单库相比较,使用一主一从的结构本质上并不能提供太多的性能上的提升,因为从库完整的重演了主库的写操作,并且承担所有的读操作。
而且添加MyCAT作为中间件来完成集群的搭建使得执行SQL需要多经过一个route过程,因此预期MyCAT集群的响应时间和QPS都应当低于单库指标,理想结果为与单库的差距不超过10%。
总体延时对比(ms)
![](https://img-blog.csdn.net/20160717142840256?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
总体QPS对比
![](https://img-blog.csdn.net/20160717142929071?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
5x1000W数据量对比,左侧为响应时间,右侧为QPS
![](https://img-blog.csdn.net/20160717142952587?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
5x5000W数据量对比,左侧为响应时间,右侧为QPS
![](https://img-blog.csdn.net/20160717143011509?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
测试结果总结:
从5x1000W组的测试数据可以看到添加MyCAT作为中间件,明显的提高了响应时间,QPS也有所降低,当数据量增大以后,在5x5000W组的测试结果中,MyCAT表现出了对单库的性能上的提升,同时响应时间也有最多达10%以上的降低,需要注意的是,当采用256线程并发时,MyCAT服务器已经出现了较高的线程切换等待,所以MyCAT在高并发下的表现应该还有提升的空间。
由于没有join操作,瓶颈集中在磁盘IO。
测试结果超过预期,可以预见在数据量较高,且并发压力较大的情况下,MyCAT集群(主->多从)会有更好的表现。
测试内容备注:
测试脚本中,读操作包括:单行数据查询;使用between进行范围查询,且范围查询没有跨数据分片;使用between进行范围查询,包含排序操作order by,且范围查询没有跨数据分片。写操作包括:单行数据的insert………on duplicate update…….和单行数据的删除操作delete…..where……。
测试脚本中不包含join。
测试环境采用虚拟机的方式进行,虚拟机的配置如下:
主库:
CPU:Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz,逻辑核心8个
内存:32GB
硬盘:250G
从库:
CPU:Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz,逻辑核心8个
内存:32GB
硬盘:250G
MyCAT服务器:
CPU:Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz,逻辑核心4个
内存:8GB
硬盘:250G
测试方法最终以Sysbench为准,测试项目分为MySQL单库与MyCAT集群,集群中已经使用范围分区策略对所有测试用表进行了分区,并且进行了读写分离,写操作只在主库,读操作只在从库。
具体测试项目及结果如下表
| 单库 | MyCAT | 单库 | MyCAT | 单库 | MyCAT |
线程 | 64 | 64 | 128 | 128 | 256 | 256 |
5x1000W | ü | ü | ü | ü | ü | ü |
5x5000W | ü | ü | ü | ü | ü | ü |
对勾为测试通过,叉号为测试不通过,是否通过以最终响应时间为标准,平均响应时间超过500ms则认为测试不通过。按照并发线程数依次列出测试结果。512线程并发由于MyCAT服务器性能成为瓶颈,放弃对比测试。
测试结果预期:
由于MyCAT-MySQL集群本身的功能还没有全部实现,因此测试用脚本采用一些特殊处理,具体内容见附录-测试内容备注。
由于使用了严格的读写分离,和单库相比较,使用一主一从的结构本质上并不能提供太多的性能上的提升,因为从库完整的重演了主库的写操作,并且承担所有的读操作。
而且添加MyCAT作为中间件来完成集群的搭建使得执行SQL需要多经过一个route过程,因此预期MyCAT集群的响应时间和QPS都应当低于单库指标,理想结果为与单库的差距不超过10%。
总体延时对比(ms)
总体QPS对比
5x1000W数据量对比,左侧为响应时间,右侧为QPS
5x5000W数据量对比,左侧为响应时间,右侧为QPS
测试结果总结:
从5x1000W组的测试数据可以看到添加MyCAT作为中间件,明显的提高了响应时间,QPS也有所降低,当数据量增大以后,在5x5000W组的测试结果中,MyCAT表现出了对单库的性能上的提升,同时响应时间也有最多达10%以上的降低,需要注意的是,当采用256线程并发时,MyCAT服务器已经出现了较高的线程切换等待,所以MyCAT在高并发下的表现应该还有提升的空间。
由于没有join操作,瓶颈集中在磁盘IO。
测试结果超过预期,可以预见在数据量较高,且并发压力较大的情况下,MyCAT集群(主->多从)会有更好的表现。
测试内容备注:
测试脚本中,读操作包括:单行数据查询;使用between进行范围查询,且范围查询没有跨数据分片;使用between进行范围查询,包含排序操作order by,且范围查询没有跨数据分片。写操作包括:单行数据的insert………on duplicate update…….和单行数据的删除操作delete…..where……。
测试脚本中不包含join。
相关文章推荐
- java设计模式-工厂模式
- CTF百密一疏——凯撒密码
- POJ2393————Yogurt factory (贪心)
- xxx
- POJ3258(最大化最小值)
- MediaPlayerManager
- Android Studio 构建项目一直卡在 gradle build running 解决方法
- [暑假集训] jzoj 2016.7.17 noip模拟赛C&B 总结
- genymotion 启动模拟器"unable to start the virtual device"问题解决
- gulp + browserSync 一起提高前端开发效率吧!
- jzoj 1365. 【队列练习】奇怪的电梯
- 深入浅出 RecyclerView
- css3学习以及移动端开发基本概念的思考
- hihocoder-平衡树·SBT
- 利用 libevent 实现简单 http client GET、POST
- handler浅谈
- HTML iframe 用法小总结
- linux系统中怎么结束boa进程?
- gcc选项 -D_REENTRANT机制
- 晃动动画加震动