最近的项目使用了纯node服务,之前都是用node做些小工具并没有接管过大流量的线上服务,这次要实现对线上服务进行小流量切流,服务器的抗压能力得需要准确的预估。通过团队QA同学的介绍选用了JMeter这个压测工具,讲真还挺好用的,基本可以实现5分钟上手。
1. JMeter简介
JMeter是一个跨平台工具,能够运行在任何安装了Java虚拟机的操作系统(Windows, Linux, Mac)的设备上。 它的框架支持并发和多线程或者线程组的执行。这对于配置负载测试和压力测试非常有用。 它是可扩展的,提供了大量的可用插件。 JMeter是Apache软件基金会下的一个子项目,是完全免费和开源的
1.1 Apache JMeter 功能包括:
-
能够加载和测试许多不同的应用程序/服务器/协议类型:
- Web的HTTP,HTTPS(java,Nodejs,PHP,ASP.NET,…)
- SOAP / REST Webservices
- FTP 文件传输协议
- Database via JDBC
- LDAP
- Message-oriented middleware (MOM) via JMS
- 邮件传输协议 - SMTP(S), POP3(S) 和 IMAP(S)
- 本地命令或Shell 脚本
- TCP
- Java Objects
-
全功能测试IDE,允许快速记录测试计划(来自浏览器或本地应用程序),构建和调试。
-
基于Java开发,支持Linux、Windows、MAC OSX等平台。
-
可以生成完整的动态HTML报告。
-
通过从最流行的响应格式、HTML、JSON、XML或任何文本格式提取数据的能力,可以轻松地进行相关性。
-
全多线程框架允许多线程并发采样,同时通过不同的线程组进行不同功能的同时采样。
-
缓存和离线分析/重放测试结果。
-
高度可扩展内核, 数据分析和可视化插件可扩展,可通过Maven、Gradle和Jenkins实现持续集成。
2. JMeter 安装-Mac
进入JMeter的官网下载地址页面,如下图有两个版本可供下载:
- Binaries:二进制版,即已经编译好、可直接执行 (建议首选);
- Source:源代码版,需要自己编译;
3. JMeter 使用
3.1 启动
进入解压目录找到 /apache-jmeter-5.4.1/bin/jmeter,双击jmeter就会启动
3.2 构建测试计划
启动jmeter后,jmeter会自动生成一个空的测试计划,用户可以基于该测试计划模板建立自己的测试计划
3.2.1 添加虚拟用户组
右击TestPlan>Add>Threads(Users)>Thread Group
图中设置的意思是模拟10个用户5秒内重复发起2次请求,下面的描述帮助理解这3个选项
- Threads线程数: 这里就是指虚拟用户数,默认的输入是“1”,则表明模拟一个虚拟用户访问被测系统,如果想模拟100个用户,则此处输入100。
- Ramp-Up 时间 (秒): 虚拟用户增长时长。不明白别着急,举个例子:比如你测试的是一个考勤系统,那么实际用户登录使用考勤系统的时候并不是大家喊1、2、3 - 走起,然后一起登录。实际使用场景可能是9点钟上班,那么从8:30开始,考勤系统会陆陆续续有人开始登录,直到9:10左右,那么如果完全按照用户的使用场景,设计该测试的时候此处应输入40(分钟)* 60(秒)= 2400。但是实际测试一般不会设置如此长的Ramp-Up时间,原因嘛,难道你做一次测试要先等上40分钟做登录操作?一般情况下,可以估计出登录频率最高的时间长度,比如此处可能从8:55到9:00登录的人最多,那这里设置成300秒,如果“线程数”输入为100,则意味着在5分钟内100用户登录完毕。
- loop count循环次数:该处设置一个虚拟用户做多少次的测试。默认为1,意味着一个虚拟用户做完一遍事情之后,该虚拟用户停止运行。如果选中“永远”,则意味着测试运行起来之后就根本停不下来了,除非你把它强制终止。
3.2.2 添加被测页面
右键刚才的用户组
3.2.4 添加测试报表
添加完之后是这个样子
报告需要在启动测试之后才能看到,样式如下
4. 实战记录
4.1 1s压测结果记录:
50qps
100qps
200qps
400qps
800qps
1600qps
4.2 30s压测结果记录:
3000线程数,丢了1000
2400线程数,丢了400
发现线程数超出2000就会丢请求,查阅相关资料确实存在这个问题,于是压测方案改成2000线程+循环数来实现理想压测
2000 线程-cpu 18.75% 66.67QPS
2000线程2次循环-cpu 35.45% 133QPS
2000线程3次循环–cpu 60.5% 200QPS
2000线程4次循环-cpu 66.67% 266.67QPS
初步结论:最佳qps在70左右,单台极限值在500左右
4.3 验证最佳值
1000线程循环21次压5分钟,模拟70qps(21000次请求),从数据来看单台实例70QPS基本就是是最佳状态,cpu只到70%(cpu数据是指使用率通过公司内部平台获得的),单台可以支持1512000pv(计算公式:每天总 PV = QPS * 3600 * 6)
备注:服务器实例配置cpu: 2核,内存: 512MB
目前业务已上线2周多,没有任何宕机事故,SLA指标100%。