（十二）性能测试-一次完整的压测

测试对象

本次测试对象为Java开发的用户行为采集系统，只要用户在客户端有相应的用户行为，就会触发数据采集系统收集并记录这些数据到数据库。

测试目的

1.验证现有集群环境，数据采集系统是否能够将tps提高到2000以上且稳定运行。
2.找出当前集群环境的性能瓶颈。
3.验证消息中间件RabbitMQ处理大量数据的效率。

部署架构

01.png

nginx集群环境部署在同一台服务器上，Jmeter部署在另外一台直连服务器上，各个应用中间件按照生产标准优化。

测试脚本

Jmeter脚本中包含用户行为采集的各个接口对应的http请求，不添加任何脚本策略。

02.png

测试结果

case1：500个线程，5秒启动，持续运行600秒

响应时间小于3S，错误率为0.0%，吞吐率为10963.5/sec

03.png

CPU使用率74.5%，内存剩余25G

04.png

case2：1000个线程，5秒启动，持续运行600秒

1000个线程下，吞吐量明显下降，错误响应比例高达7%，服务器资源开始出现空闲，说明当前集群无法满足该性能压力

05.png

06.png

case3：800线程，5秒启动，持续运行600秒

响应时间小于3S，错误率为4.65%，吞吐率为9479.2/sec

07.png

CPU使用率75.9%，内存剩余23G

08.png

case4：Jmeter注入1400万条数据，观察并记录RabbitMQ效率

500个线程循环4000次（用时21分30秒）

09.png

Jmeter运行完毕后MQ排队情况

10.png

mysql数据写入情况

11.png

测试总结

1.通过case1可以看出，当前集群环境完全可以满足tps>2000的响应需求，并且在500个线程压力下tps可以稳定在10000左右稳定运行。

2.通过对case1、case2、case3的测试结果，当线程数为500的时候，系统稳定运行；当线程数为1000的时候，系统开始出现高达7%的错误响应且服务器资源空闲，tps较case1下降；当线程数为800的时候，响应的错误率下降为4.6%且服务器资源开销正常，tps较case2有所提升；推测当前集群环境能够承受的Jmeter线程数在500~800之间，最大tps在10000左右。

3.通过Jmeter向系统注入1400万条数据，系统总处理时间为1小时19分33秒，数据没有丢失情况。Jmeter在21分30秒时候就已经停止请求，此时RabbitMQ中缓存了大概1260万条消息，处理花费59分钟，系统在没有请求压力情况下平均每分钟处理21万条数据，在有Jmeter压力请求压力下平均每分钟处理6.5万条数据。