支付系统-1.3.4版本部署性能测试

1.3.4版本更新

1.所有消息都改为异步发送，消息子系统部分方法改为异步调用

2.tcc事务开始支持子事务异步调用

3.添加web程序中添加了限流器，设置的流量阈值为1500次/s，以保障系统不会被高流量冲垮

 

1.3.4测试：

测试环境介绍：

service服务：10.8.59.158（gen8,12cpu）,10.8.59.179（gen9,12cpu）,10.8.59.170（gen8，12cpu）,10.8.59.169（gen8，12cpu）,10.8.59.203（gen9，12cpu）

tomcat，zookeeper单机，dobbo-monitor，mycat-eye：10.8.59.169（gen8,12cpu）

activemq单机：10.8.59.179

redis-cluster（三主三从）：10.8.59.208（gen9,16cpu）

mycat:10.8.59.176(gen9,12cpu)

account表（未分表）：10.8.59.168（gen9,16cpu）

point表（未分表）：10.8.59.176

order表（水平拆成5份）：order1主从（10.8.59.176），order2主从和order3主从（10.8.59.206 ，gen9,12cpu），order4主从和order4主从（10.8.59.208）

base_message_accounting：10.8.59.169

task与队列消费任务：10.8.59.73（pc机，4cpu）,10.8.59.74（pc机，4cpu）

请求产生：10.8.59.74（pc机，4cpu）

共计9台服务器与两台pc机

 

本次测试共使用了两个不同的压力进行测试：

1.19:45-20:00，使用test模块30个线程并发产生支付请求，共60W条

2.20:00-20:10，使用test模块40个线程并发产生支付请求，共80W条

3.20:42-21:00，使用test模块50个线程并发产生支付请求，共100W条

4.20:18-21:35，使用test模块60个线程并发产生支付请求，共120W条

以下是调用时部分截图

链接：https://pan.baidu.com/s/1NrQB-hPk0f--AwK4W93xqA 密码：hkou

测试结果dubbo调用情况部分截图：

可以看到，第三次与第四次测试，尽管增加了请求的线程数，但是QPS并没有显著的提高，说明此时系统应该是遭遇到了一个瓶颈，通过分析各个服务器的cpu与io情况，可以得出结论，以下是最后一次测试时的一些截图：

上图是各个节点的cpu负载截图，可以看到此时各个节点的load average都处于一个不低的水平，部分服务器，如206,176等都已经处于一个较高的水平，基本已经不能承受更高的压力。

上图是mycat服务器网络io消耗截图，可以看到作为整个系统中io的最大负载点，mycat的收发速率都已经达到了90+M/s,马上就要触及千兆网的极限，估计这也是QPS无法继续上升的症结。

上图是各个服务节点的网络io消耗，可以看到这些服务器的网络io还是有比较大的富余的，暂时无需扩容整改。

上图是mysql服务器的磁盘io消耗截图，可以看到各个服务器的磁盘io消耗已经处于一个不低的水平，基本都已经超过了50%，10.8.59.206的几次顺时io已经超过了70%，若要支持更高的QPS，增加数据库的服务器投入也是刻不容缓的。

相对于1.3.3版本的测试，我们可以看到在相同的压力下，1.3.4的QPS更高，可以看出将tcc的子事务改为异步发送还是起到了不小的作用。

若要继续提高QPS，目前看来当然是需要更多的服务器，同时需要对网络进行改造，若能升级为万兆网络当然是最直接的，但是并搞不到万兆交换机，同时服务器的网卡也只支持千兆，另一个方案是再安装一个mycat，分流一部分非主业务到新的mycat上，从而分流原mycat的网络io压力，等我有更多的服务器了，再来测试吧。