微信小程序性能测试之jmeter踩坑记录（二）

接上篇：微信小程序性能测试之jmeter踩坑记录（一），经过前面大半个月的摸鱼，流程是走了一遍，但结果好像没那么清晰，也没有具体的解决方案，日子在逼近，加上运营的催促，于是老大亲自主导，考虑到我们的经验不足，决定引入外援。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

经历过几天的讨论风声后，敲定了一个合作方，并发来了一个需求调研文档，并表示后面会陆续派人过来对接。

需求调研文档包括，需求目标以及现有系统架构图。比起我们模糊的定义，他们仅用了一句话就概括了目标：活动预计会达到50w用户的同时登录下单操作，所以需要系统能够承受住50W的并发，其中登录50w并发，下单转化率3%为1.5W并发。

 典型的系统架构如下：

 

确认后合作方先派人过来熟悉项目了，不久便出了一个测试计划，包括每个阶段以及对应的测试时间与负责人。

测试工具开发—测试环境准备—中间件压测—单机压测—新生产环境准备—确定新生产环境预算—新生产环境切换—所有测试工作完成—测试报告+建议—新生产环境中间件升级—高性能新生产环境试运行—redis数据同步至mysql—生产系统回切

计划压力测试分为中间件压力测试，线性压力测试，单机压力测试三个轮次，由于本地没有测试环境，直接在阿里云申请服务器并搭建测试，记录如下：

中间件压力测试

中间件轮次主要测试系统的各种中间件是否能承受住目标并发的压力，包括Rds，Redis，SLB，可简单分为以下三步。

第一步：进行压测脚本开发，模拟后台程序产生业务压力，对redis和Rds（mysql）进行请求，以达到用最少的硬件资源在最少的时间内处理最多的请求的目的。

第二步：进行压测环境搭建，压测工具为apache benchmark，分别部署在16台阿里ecs服务器组成的集群（集群a）里，模拟后台的压测脚本被部署在另外16台用相同规格的ecs组成的集群（集群b）里，集群b由一个负载均衡slb平均分配压力

第三步：进行压力测试，并统计ab压测的rps（request per second 每秒处理请求数 即并发数）等结果，通过计算rps即可看到目标并发数下的redis和rds中间件的负载等参数，便可分析中间件是否能承受目标压力

时间计划（略）

中间件测试案例如下：

场景	目标	案例
Redis	单次登录写入的缓存大小	清空Redis缓存，前端登录，查看Redis缓存大小
	单次下单业务写入的缓存大小	清空Redis缓存，前端操作完成一次下单业务，查看Redis缓存大小
	连接数	登录rps压力50W+订单rps压力1.5W，Redis连接数
	带宽	登录rps压力50W+订单rps压力1.5W，Redis带宽
	QPS	登录rps压力50W+订单rps压力1.5W，Redis QPS
	CPU	登录rps压力50W+订单rps压力1.5W，Redis CPU使用率
MySql	连接数	登录rps压力50W+订单rps压力1.5W，MySql 连接数
	带宽	登录rps压力50W+订单rps压力1.5W，MySql 带宽
	IOPS	登录rps压力50W+订单rps压力1.5W，MySql IOPS
	CPU	登录rps压力50W+订单rps压力1.5W，MySql CPU使用率

RDS（MySQL）测试结果

本次测试的RDS为60核顶配版，测试时，使用了2台A机和2台B机。其中1台A机发送的命令如下图所示：

 

可知1台A机会开4个线程，对应1台B机发送压力请求，故2台A机共8个线程对应2台B机发送压力。下图是某1个线程的压力测试结果：

 

图中的Request per second代表并发数，该图表示该线程的测试结果并发数为1422。经统计，8个线程的并发数平均值为1400，故此次测试系统总并发数为8*1400=11200。

同时查看系统资源负载情况（图略），RDS的CPU使用率接近40%，空闲CPU充裕。会话连接数为641，而该RDS的最大连接数为100000。IOPS为501，而该RDS的最大IOPS为50000。TPS/QPS为57139，QPS代表每秒执行的查询次数，而本次测试1次请求并发需要执行4次查询，故RDS显示的QPS计算可得知并发数为57139/4=14284，与AB压力测试工具的结果11200接近。

综上所述，在系统下订单时并发数达到1.1~1.4万的时候，RDS的QPS为4.4~5.6万，RDS的各项硬件负荷正常，RDS运转正常，完全可以应对下订单时的1.5万并发需求。

 Redis（集群）测试结果

本次测试的Redis为256G集群版，测试时，使用了16台A机和16台B机。其中1台A机发送的命令如下图所示：

由上图可知1台A机对应1台B机同时使用4个线程发送压力请求。下图是某1个线程的压力请求结果：

由上图可以看出Request per second 即并发数为5850，经过数据的统计得出16台A机，每台A机4个线程，共16*4=64个线程的平均RPS为5850，故本次测试的总并发数为64*5850=374400。

下图是Redis在系统37.44万并发时的各项硬件指标：

注意到上图其余指标正常，而CPU占用率已经达到了90%。

综上所述，在系统登录并发达到37.44万时，256G集群版本的Redis的CPU已经达到极限，考虑到登录的目标并发数为50万，故该版本的Redis暂不能支撑如此高的并发，推荐使用512G集群版甚至1T集群版的Redis更为稳妥。

SLB（负载均衡）测试结果

本次测试采用的负载均衡规格为slb.s3.large，最大连接数为1000000，最大CPS为100000，最大QPS为50000，最大外网带宽为5120Mbps。

测试时，模拟了流量最大的接口。

1台A机同样采用了4线程发起压力，下图是其中1条线程的压力结果：

由上图可知Request per second即并发数为5245，经统计所有测试结果计算后得出RPS平均数为5240。

本次SLB测试采用了分阶梯测试，分别采用1台，2台，4台，8台，16台A机发起压力测试，并统计分析测试结果。

同时查看SLB流入流量情况（图略），分析可知，SLB的带宽占用随着A机的数量呈线性增长，其比例大致为带宽占用为A机数量*100Mbps。而1台A机的RPS为5240*4=20960，如果要达到50万的RPS，则需要的A机台数为500000/20960=23.85台，即24台，则SLB带宽为24*100=2400Mbps。该次测试用的SLB最大带宽为5120Mbps，故当系统达到50万并发时，负载均衡SLB带宽占用仅使用一半不到，完全满足目标的需求。

中间件测试结果总览

注意：由于测试设备有限（未买到512G以上的Redis），以下均为登录33万并发，订单1.5万并发的测试结果数据

场景	目标	案例	结果
Redis	单次登录写入的缓存大小	清空Redis缓存，前端登录，查看Redis缓存大小	7.08Mb/1w
	单次下单业务写入的缓存大小	清空Redis缓存，前端操作完成一次下单业务，查看Redis缓存大小	(formId 1.77Mb/1w)
	连接数	登录rps压力33W+订单rps压力1.5W，Redis连接数
	带宽	登录rps压力33W+订单rps压力1.5W，Redis带宽	流入56.9M，74.5M流出
	QPS	登录rps压力33W+订单rps压力1.5W，Redis QPS	701722
	CPU	登录rps压力33W+订单rps压力1.5W，Redis CPU使用率	90.2%
MySql	连接数	登录rps压力33W+订单rps压力1.5W，MySql 连接数	587
	带宽	登录rps压力33W+订单rps压力1.5W，MySql 带宽	流入35.1M，流出52.8M
	IOPS	登录rps压力33W+订单rps压力1.5W，MySql IOPS	501
	CPU	登录rps压力33W+订单rps压力1.5W，MySql CPU使用率	37%

本次对中间件的压力测试结果数据分析表明：当使用slb.s3.large版负载均衡时，能承受住50万并发的流量冲击。当使用60核顶配RDS（MySQL）数据库时，能承受住1.5万的订单并发压力。当使用256G的Redis集群版时，登录场景最多能承受住33万左右的并发压力，推荐使用512G以上的Redis配置

---------------------------------------------------------------------------------------未完待续-------------------------------------------------------------------------------