用户体验 = 产品设计(非技术)+ 系统性能(快)
首屏时间 = DNS时间+建立连接时间+后端响应时间+网络传输时间+首屏页面渲染时间
FPS : 是体现页面顺畅程度的一个重要指标。
端到端响应时间 = DNS解析时间+后端响应时间+网络传输时间
阿里云:5台4C8G机器,4台压力机2C4G
服务器环境:1台压力机,1台应用服务主机,1台数据库与缓存服务器,1CICD服务器
只有在系统基础功能测试验证完成、系统趋于稳定的情况下,才会进行压力测试。
指标 | 含义 |
---|---|
响应时间(RT) | 系统对请求作出响应的时间。对于单用户的系统,响应时间可以很好地度量系统的性能 |
吞吐量 | 系统在单位时间内处理请求的数量。每秒事务数TPS是吞吐量的一种 |
并发用户数 | 系统可以同时承载的正常使用系统功能的用户的数量。用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求 |
错误率 | 失败请求占比。在测试时添加响应断言,验证不通过即为错误;若不添加,响应码非200即为错误 |
资源利用率 | cpu占用率、内存使用率、系统负载、网络I/O |
Apache JMeter最初被设计用于web应用测试,但后来扩展到其他测试领域。用于测试静态和动态资源,例如静态文件、java小服务程序、CGI脚本、java对象、数据库、FTP服务器等。用于对服务器、网络或对象模拟巨大的负载,来自不同压力类别下测试它们的强度和分析整体性能。另外,能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证程序返回了你期望的结果。
新建测试计划 --》右键“添加”–》线程用户–》线程组
配置线程组:线程数 20;ramp-up 指定时间之内把这些线程全部启动起来(如1,表示1s内把20个线程全部启动起来);循环次数 2000 表示把20线程循环2000次,也就是说让线程循环调用接口2000次
配置HTTP接口:选择keepalive方式,表示使用了长连接(长连接防止频繁建立连接,关闭连接消耗性能)。如果不勾选,压测部分性能消耗会发生在建立,关闭连接上,导致我们的压测数据不准确。
配置断言:一种是响应断言,一种是响应时间断言,如果响应内容不满足断言的配置,则认为这次的请求是失败的。右键测试计划的http请求,选择添加–》断言–》加断言和断言持续时间。
配置结果监听:监听压测结果【聚合报告和汇总报告很类似】
label | 样本 | 平均值 | 中位数 | 90%百分位 | 95%百分位 | 99%百分位 | 最小值 | 最大值 | 标准偏差 | 异常% | 吞吐量 | 接收KB/sec | 发送 | 平均字节数 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
http | 100000 | 5921 | 6206 | 7108 | 7587 | 8883 | 1 | 17300 | 1576.95 | 0.00% | 779/sec | 341.57 | 0.00 | 449 |
线程组用来模拟一组用户访问系统资源(API接口)。可以使用JMeter的分布式测试功能,通过一个JMeter的Master来远程控制多个JMeter的Salve完成测试。
增加新的内容分析维度:QPS 、RT、压力机活动线程数(表明压测过程中施加的压力的情况)、服务器资源信息等。
下载地址:http://jmeter-plugins.org/downloads/all/,官网上下载plugins-manager.jar直接在线下载,
average response time:平均响应时间;active threads 活动线程数;Bytes Throughput 吞吐量;Connect Times连接时间
使用操作系统命令:top -H、vmstat、iostat、iotop、dstat、sar;使用finalshell;使用JMeter压测工具PerfMon;使用Grafana+Prometheus+node_exporter
## 默认启动运行 startAgent.sh 脚本即可
## 服务启动默认4444端口,根本连接不上,因此自己创建一个部署脚本文件对此进行部署,且把端口修 改为7879
nohup java -jar ./CMDRunner.jar --tool PerfMonAgent --udp-port 7879 --tcp- port 7879 > log.log 2>&1 &
## 赋予可执行权限
chmod 755 startAgent.sh
好处:将所有信息汇总到JMeter工具中,查看方便。 缺点:数据记录时间有限,记录数据的量也有限
系统负载System Load是系统CPU繁忙程度的度量,既有多少进程在等待被cpu调用(进程等待队列的长度)
平均负载(Load Average)是一段时间内系统的平均负载,这个一段时间一般取1分钟、5分钟、15分钟
多核CPU和单核CPU的系统负载数据指标的理解还不一样
指标范围
【0.0 - 0.7]】 :系统很闲,马路上没什么车,要考虑多部署一些服务
【0.7 - 1.0 】:系统状态不错,马路可以轻松应对
【等于1.0】 :系统马上要处理不多来了,赶紧找一下原因
【大于5.0】 :马路已经非常繁忙了,进入马路的每辆汽车都要无法很快的运行
问题分析
# 更新包
yum update
# 安装需要的软件包
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
# 设置yum源为阿里云,加速下载
sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker- ce/linux/centos/docker-ce.repo
# 安装docker
sudo yum install docker-ce
# 安装后查看docker版本
docker -v
# #### #### ####安装InfluxDB
# 下载influxDB的镜像
docker pull influxdb:1.8
# 启动InfluxDB的容器,并将端口8083和8086映射出来
docker run -d --name influxdb -p 8086:8086 -p 8083:8083 influxdb:1.8
# 进入容器内部,创建名为jmeter的数据库
docker exec -it influxdb /bin/bash
# ## 容器系统命令
influx
# Connected to http://localhost:8086 version 1.7.10
create database jmeter
show databases
想要将 JMeter的测试数据导入 InfluxDB ,就需要在 JMeter中使用 Backend Listener 配置。
docker pull grafana/grafana
docker run -d --name grafana -p 3000:3000 grafana/grafana
# 网页端访问http://127.0.0.1:3000验证部署成功
# 下载
wget -c https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_ex porter-0.18.1.linux-amd64.tar.gz
# 解压
tar zxvf node_exporter-0.18.1.linux-amd64.tar.gz -C /usr/local/hero/
# 启动
cd /usr/local/hero/node_exporter-0.18.1.linux-amd64
nohup ./node_exporter > node.log 2>&1 &
注意:在被监控服务器中配置开启端口9100 .127.0.0.1:9100/
# 下载
wget -c https://github.com/prometheus/prometheus/releases/download/v2.15.1/prometheus -2.15.1.linux-amd64.tar.gz
# 解压
tar zxvf prometheus-2.15.1.linux-amd64.tar.gz -C /usr/local/hero/
# 运行
nohup ./prometheus > prometheus.log 2>&1 &
#配置 Prometheus.yml中加入如下
- job_name: 'hero-Linux' static_configs: - targets: ['172.17.187.78:9100','172.17.187.79:9100','172.17.187.81:9100']
测试是否安装配置成功:http://127.0.0.1:9090/targets
在Grafana中配置Prometheus的数据源:
导入Linux系统dashboard(如ID:11074、16098)
压测接口:响应时间20ms,响应数据包3.8kb,请求数据包0.421kb
1Gbit/s = 1Gbps = 125MB/s
1Mbps = 1Mb/s = 0.125MB/s
梯度压测,测出瓶颈
进一步提升压力,发现性能瓶颈
线程数 5,循环5000次,共2.5万个样本;线程数10,循环5000次,共5w样本;… 线程数40,循环5000次,共20万个样本。
网络到达瓶颈:随着压力的上升,TPS不再增加,接口响应时间逐渐在增加,偶尔出现异常,瓶颈凸显。系统的负载不高。cpu、内存正常,说明系统资源利用率不高,带宽已经触顶了。
优化方案:降低接口响应数据包大小;提升带宽。
服务端线程数:TPS/RT*1000(如 RT=1000ms,TPS=800,线程数=800)
接口的响应时间是否正常?是不是所有的接口响应都这么快
高延时场景:用户访问接口并发逐渐增加的过程。接口的响应时间为500ms(模拟sleep 500)
结论:在高延时场景下,服务器瓶颈主要在容器最大并发线程数(800/RT*1000);
TPS在上升到一定的值之后,异常率较高:理解为与IO模型有关系,因为当前使用的是阻塞式IO模型。这个问题我们在服务容器优化部分解决。
使用JMeter做大并发压力测试的场景下,单机受限与内存、CPU、网络IO,会出现服务器压力还没有上去,但是压测机压力太大已经死机!为了让JMeter拥有更强大的负载能力,JMeter提供分布式压测能力。
wget https://mirrors.tuna.tsinghua.edu.cn/apache//jmeter/binaries/apache- jmeter-5.4.1.tgz
tar -zxvf apache-jmeter-5.4.1.tgz
mv apache-jmeter-5.4.1 ./apache-jmeter-5.4.1-salve
# 配置修改rmi主机hostname
# 1.改ip
vim jmeter-server
# RMI_HOST_DEF=-Djava.rmi.server.hostname=本机ip
# 2.改端口
vim jmeter.properties
# RMI port to be used by the server (must start rmiregistry with same port)
server_port=1099
# To change the default port (1099) used to access the server:
server.rmi.port=1098
# 配置rmi_keystore.jks
# 启动jmeter-server服务
nohup ./jmeter-server > ./jmeter.out 2>&1 &
Queries Per Second(每秒查询率),每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准,在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
对应fetches/sec,即每秒的响应请求数,也即是最大吞吐能力。
计算公式:
qps = 请求查询数 / 秒
qps = fetchs / per second
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
qps相当于最大吞吐率
Requests Per Second(每秒发送请求数/吞吐率),指客户端每秒发出的请求数。阿里云PTS 对于这个词的解释为RPS有些地方也叫做QPS,在不单独讨论“事务”的情况下可以近似对应到Loadrunner/jmeter的TPS(Transaction Per Second, 每秒事务数)。
计算公式:
吞吐率 = 总请求数 / 处理这些请求的总完成时间
Requests per second = Complete requests / Time taken for tests
吞吐率是服务器并发处理能力的量化描述,单位是reqs/s,指的是某个并发用户数下单位时间内处理的请求数。
某个并发用户数下单位时间内能处理的最大的请求数,称之为最大吞吐率。
截图来源:《并发模式与 RPS 模式之争,性能压测领域的星球大战》
链接:https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247487138&idx=1&sn=be66769443f8157461c9ef12cba7722c&chksm=fdeb3cc2ca9cb5d423dceb71977e01a07be3be552a9b7cc63afec96936ee0b14ef07ff602345&token=1058504863&lang=zh_CN#rd
Transactions Per Second(每秒传输的事物处理个数),即服务器每秒处理的事务数。TPS一般包括一条消息入和一条消息出,加上一次用户数据库访问。(业务TPS = CAPS × 每个呼叫平均TPS)
CAPS: Call Attempts Per Second (每秒建立呼叫数量)
TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。
一般的,评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。
Reponse Time(响应时间),从发起请求到完全接收到应答的时间消耗。
同时访问服务器站点的连接数。
建议参考文章:https://www.cnblogs.com/xiaowenshu/p/10727523.html
(The number of concurrent connections)
并发连接数就是服务器某个时刻所接受的请求数目,也就是某个时刻所接受的会话数目。
(The number of concurrent users, Concurrent Level)
一个用户可能产生多个会话,所以并发用户数和并发连接数并不重复。并发用户数是指服务器某个时刻所能接受的用户数。
(Time per requests)
计算公式:
用户平局请求等待时间 = 总时间 / (总请求数 / 并发用户数)
Time per requests = Time taken for tests / (Complete requests / Concurrent Level)
(Time per requests: across all concurrent requests)
计算公式:
服务器平均等待时间 = 总时间 / 总请求数
Average request latency server = Time taken for tests / Complete requests
程序运行中消耗cpu的线程数,在正常消耗范围内线程数越大越好。
吞吐量,是指在一次性能测试过程中网络上传输的数据量的总和。