【mysql】-mysql读写分离后性能到底能提高多少(实测)

尽人皆知,Mysql通过读写分离分库分表后性能会有提升,那么如果仅配置主从复制,读写分离到底能提升多少呢?

网上逛了一圈也没有找到什么可以参考的数据,还是实践出真知,自己实际测一番便可知晓.

环境描述:

项目我采用生产环境的一个项目,数据也拷贝了一份(核心几张表数据均超百万),然后选取了其中一个并发度最高的接口,且该接口既有读操作又有写操作.

打压工具我用截止目前发帖时间jmeter最新版本5.1.1

两台服务器配置:

华为云 centos 7.3 5M带宽 4核16G内存 做主库,也是写库. 项目也部署在该服务器上

联通 centos 7.3 10M带宽 8核32G内存 (实际上这台服务器比华为云渣,谁用谁知道,网速卡的一批) 读库,实时从主库复制数据

数据库: mysql 5.7

中间件: mycat 1.6

架构:一主一从

虽然这两台服务器实际情况都比较渣,还有一些测试项目在上面跑着,但大的方向不会对整体测试结果造成很多影响.

---

测试组一:

未采取读写分离,模拟500个并发,请求1万次,下面是测试数据和结果截图:

 从上图我们可以看到,吞吐量大致在52.4/s,请求平均耗时5714毫秒.

当然我还模拟过1000个并发,100W条请求,以让样本足够大,但跑起来太耗时间了,结果与这个类似,我大概跑了一半就关了,所以数据就不贴了.

---

测试组二:

通过Mycat的9066管理端口进入,可以看到,写负载和读负载已经完全分离了.

主从复制,读写分离我已经搭好并测试过了,具体的配置方法可以参考这篇:

https://blog.csdn.net/lovexiaotaozi/article/details/83022009

用Mycat配置读写分离,同样的接口参数,模拟500个并发,发送1万个请求,测试结果如下:

表现的确有变好一些,但似乎没变好多少,有点差强人意,不过我依旧不想质疑读写分离后对性能的提升,毕竟我这个接口只涉及了一个查询操作和一个读操作,如果是对于读操作明显多于写操作的接口,应该会有更明显的提升,而且在整个项目中有那么多接口,每个接口都有提升的话,抛去各种干扰因素,总体性能提升还是很大的.另外我甚至还怀疑是我本地的带宽比较低,我开500个线程用Jmeter发请求时,本机电脑的网络已经连其他网页都打不开了,所以可能本地带宽也是瓶颈,以及这台非常不稳定的联通服务器(有时候非常慢,尽管配置碾压华为云).

 

---

昨天的测试结果我胡汉三表示不满,我觉得读写分离带来的性能应该不止这点,于是我自己写了个接口,调用了业务里查询比较频繁的5个方法,和新增比较频繁的2个方法,这样才能真正模拟出性能的提升,毕竟线上这些接口在实时频繁被访问着,虽然不在同一个接口内,但对数据库来说都是一样的操作,所以有了今天的测试.

第一组:未采用读写分离

 第二组:采用读写分离

 第三组:将读库的Innodb引擎缓存myisam引擎

 

测试结果虽然依旧不尽如人意,但还是能看到有提升,另外最关键的一点是,数据库的负载相比没做读写分离有所下降,这或许也是为什么在系统发展到一定程度后都要做读写分离的原因.

文末再推荐一篇文章,关乎读写分离对性能的影响,总结的挺好的:https://my.oschina.net/candiesyangyang/blog/203425