线上质检报告压测实战

作者|李龙成

背景

线上前端node服务器cpu占满，导致访问质检报告报错，需要对线上的质检报告服务进行压力测试，了解最大并发数，以应对访问量的增长。

目的

1、发现质检报告中存在的性能瓶颈，并对性能瓶颈进行优化；

2、模拟发生概率较高的单点事故，对系统得可靠性进行验证；

3、获取线上各访问场景的性能表现，了解系统的最大承受能力；

环境

测试方案

1、测试工具

2、压测接口

3、压测场景

4、支持人员

在服务的保证上，我们分别告知了相关服务的责任人，比如Nginx、Mysql、ZZRedis和同台机器上服务的负责人，告知他们我们的压测计划，叫他们留守或者给出应急的处理方案，万一压测的过程中，相关服务挂了，可以快速恢复，防止造成大范围影响。

测试环境搭建

1、测试数据来源

由于压测线上质检报告需要线上的订单，并且要尽量少的命中缓存，所有我们从线上导出了10w条数据用于压测。

2、Jmeter分布式环境搭建

由于我们想要的并发数，使用单台机器模拟并发有些力不从心，甚至会引起JAVA内存溢出错误，所以需要分布式的形式进行施压。

使用多台机器产生负载的操作步骤如下：

（1）我们申请了4台沙箱机，分别在这4台机器上安装了jmeter，用于施压

（2） 配置agent：

server_port=1099

启动jmeter服务./jmeter-server

（3）配置master

修改 jmeter.properties remote_hosts中添加agentid，端口一定要写1099 例

remote_hosts=10.9.193.122:1099,10.9.193.87:1099,10.9.193.83:1099,10.9.186.41:1099

（4）把压测的脚本.jmx文件和数据文件分别考到对应的agent机器中

（5）本地启动jemter，选择run-remoter Start All,即可下发施压任务

3、线上服务器监控

在做压测的时候，需要对线上的服务器性能进行监控，我主要用Spotlight进行监控，由于转转的服务器都是通过堡垒机进行登录的，所以想监控机器需要做免密登录和端口转发，配置方式如下：

（1）修改ssh服务的配置文件 vi /etc/ssh/sshd_config 修改 Port 33 添加一个端口

（2）service sshd restart重启ssh服务

（3）进入/root/.ssh目录 本地系统执行 ssh-keygen -t rsa 命令，生成id_rsa私钥文件和id_rsa.pub公钥文件

（4）把公钥拷贝要监控的机器的authorized_keys里面

（5）本地启动Proxifier，启动一个socks5的代理服务

（6）设置一个匹配规则，把22端口的请求转发到本地127.0.0.1:1080上

（7）启动CRT做端口转发

用公钥登录服务器，并设置端口转发，把1080端口的请求转发到本服务器上

（8）启动spotlight，用私钥连接服务器

最后启动spotlight就能监控对应服务器的时时性能了。

测试结果与分析

这里主要对其中一个前端问题进行分析

场景描述：每秒启动10个线程，最多起100个，最大并发情况下持续运行10分钟

前端接口测试结果：业务吞吐量

前端服务器监控：

前端服务器cpu已经到达100%

后端接口测试结果：业务吞吐量

后端服务器监控：

问题分析

从整个测试过程看

前端接口当并发到达100时：前端node服务及cpu迅速占满，吞吐量也随之降低，平均响应时间增长；前端node服务有明显的性能瓶颈。

后端接口并发达到100时：业务吞吐量随虚拟用户的增加而增加，业务平均响应时间在应用服务器CPU占用率较低时保持平稳。

问题排查

分析服务器请求连接数

通过spotlight我们发现请求连接数达到6000多，而我们的qps是远远小于6000，猜测很可能是每次请求都建立了新的链接，连接一直没有及时释放，所以第一个优化点我们就在前端和后端建立连接的时候采用了长连接的形式（建立连接的时候添加keep-alive参数），复用连接，较少连接数

查看nginx log

通过分析nginx log，我们发现有些接口耗时是比较长的，而node ssr server是需要等待这些接口返回数据后才能把计算好的渲染结果返回给用户，跟相关后端同学商量，提升接口质量，同时我们把timeout从5s改为1s

结论

通过这两个优化后，我们又进行进行了一轮压测， cpu100%的问题没有复现，服务器的各种指标也正常。

其他的问题就不一一列举，具体压测的性能指标在这里不便透露。关于KeepAlive的工作原理大家可以自行搜索相关文档。