性能【搬代码】_set heap=-xms1g -xmx1g -xx:maxmetaspacesize=1024m-CSDN博客

本文链接：https://blog.csdn.net/weixin_52001174/article/details/143001188

=第一讲==
1.什么是性能测试一级性能测试的价值和目的
2.真实企业性能测试指标详解以及指标测算
3.真是企业中新跟那个测流程以及细节剖析
4.性能压测脚本自动化生成以及脚本增强和组件详解

理论–》指标–》压测脚本–》脚本完善和增强–》模拟真是场景–》压测场景–》监控平台-》平静定位和性能调优

一.什么是性能测试一级性能测试的价值和目的
性能测试就是通过性能压测工具（jmeter、loadrunner），通过特定的方式对系统施加一定的压力：正常场景压力，异常负债以及峰值来对系统实施压力，得到各项性能指标。保证系统的性能需求

价值和目的：
1.评估系统的能力
2.识别系统的弱点：瓶颈，弱点
3.去检查系统隐藏的问题（硬件不足）
4.检验系统的稳定性和可靠性

二、性能测试指标理解头侧以及测算
【虚拟用户数】：线程=用户。
【并发数】：旨在某一时间一定数量的虚拟用户同时对系统某一个功能进行交互。==一般通过集合点实现。
【事物】：一个接口可以是事务。多个接口可以是事务。一个流程可以是事务。事物代表一个完整的功能。由测试人员决定的。
【场景】：性能测试的用例（一秒钟加几个，执行几分钟）
【相应时间RT】：Response time
平均响应时间;
中位数：
90%：
95%：
99%：
基准测试：1一个用户请求接口，200-500MS（毫秒）
压力测试：N个用户并大请求接口，2s
【TPS】：是系统一个重要的性能指标，用于衡量系统在一定时间内能够处理的事务数（交易数）
如果是一个接口跟吞吐量是相等的。如果是多个接口就不一样了
Transactions per sencond
计算公式：总的事务数/总的运行时间=每秒完成多少个事务
比如某个系统1min处理1000个事务，那么TPS=1000/60=16.7
比如：按照去年经营数据，2022年最高的一天有10万比交易，预测2023年TPS需要多少算合格
总事务数=10万，时间=246060=86400s
理论TPS：100000/86400=1.2个/s（属于一天平均分的，这么做是不行的）
（1）没有更细的统计数据：根据二八定律（80%的事务在20%的时间完成）计算：
TPS：1000000.8/864000.2=4.6≈5
（2）如果有更详细的数据：其中有5万笔交易是晚上8-9点完成。
TPS=50000/3600=13.9≈14
2023年业务的增长：要考虑到2021-2022年的增长率，或者2020-2021，2021-2022平均增长率
比如业务增长率：30%
TPS=50000*（1+0.3）/3600=18
==：这个是要团队一起来做的，一起评审的，不是一个人来做
【QPS】：每一秒的查询率。QPS：一般是形容数据库
TPS、QPS、RPS：衡量服务器性能
HPS：衡量客户端的性能（客户端的每一秒的点击率,查询接口）
如果事务里面有一个接口，那么TPS=RPS。
如果接口是一个查询的接口，那么TPS=QPS=RPS、HPS。

【吞吐量】：用来衡量网络成功传输的数据量，衡量数据的传输率；单位：每秒钟运行多少个字节，Byte/s。
【资源利用率】：服务器：CPU、磁盘、网络

三、性能测试流程
1.需求分析以及需求确定（指标值，场景，环境，人员）
客户:OA项目，1万员工，并发一万（不合理）
产品经理：单台阿里云服务器，支撑1万并发，8核16G，还是8核+64G内存
项目组领导：3年之后需要达到什么样的性能。
2.性能测试的计划和方案制定
基准测试;
负债测试：
压力测试：
稳定性测试：
其他：配置测试，极限测试，浪涌测试
3.性能测试准备阶段
人力、硬件、软件、环境折算
环境干净、版本一致
4.测试执行阶段
脚本生成和增强
场景设计
指标监控
性能瓶颈定位和性能调优
php+nginx+mysql+centos要考虑：
nginx中间件的性能
mysql的性能，包扣慢查询
centos服务器的性能，cpu，磁盘
5.测试报告总结

四、性能压测脚本生成以及完善和增强
1.设置客户端的代理
控制面板->internet选项->连接->局域网设置->代理服务器：选中：为LAN使用代理服务器->地址本级地址->端口是jmeter端口->点击确定

2.录制脚本
jmeter：
-新建线程组
-HTTP Cookie管理器：【】
	很多项目之间的关联，不加会报错，加了绝对不会有问题
- HTTP代理服务器：【】
	设置请求的过滤性，
	Request Filtering中排除模式-点击添加建议排除-在输入框内最后面添加一个.*号-保存jmx-在括号内可以用|分割|wav|mp3）.*
    =包含模式（只想录制谁的就写入谁的ip）-添加-输入框写入只要查找的地址ip，如：http://192.168.0.100.index.html只写 .*192.168.0.100.* 即可
    =设置端口号
	Test plan Creation；目标控制器：测试计划>线程组；分组：在组间添加分割
	=点击启动
录制脚本完成，完善脚本

如果哪个接口有时间限制，比如3s内不能发送，或者10min不能发送，需要添加固定定时器

完善脚本以及增强脚本
token：一般用于授权
调优:http信息头管理器，很多看看哪些可以删除哪些不能删除，需要都禁用掉，然后执行，看看哪个报错就解禁掉。不报错的就可以把http信息头管理器给删除掉
将协议总结到一块儿，设置http请求默认值
jmeter的聚合报告中的吞吐量==TPS

=========================第二讲=============================
1.性能测试脚本完善以及增强
2.jmeter插件安装以及监控使用
3.性能压测场景设置（基准、负载、压力、稳定性）
4. 无界面压测场景详解

一、性能测试脚本完善以及增强
使用控制器的目的是使我们的脚本更加接近真实的场景
1.逻辑控制器:
	【事务控制器】：将几个接口放入事务控制器下面可以将他们的数据平均数相加
		事务控制器页面
			如果Generate parent sample不勾选，聚合报告会显示事务下的接口数据和独立的事务总和
			如果Generate parent sample勾选，聚合报告会仅显示设置事务下接口数据总和
	【仅一次控制器】：用来控制登录
		如果有10个用户，线程组循环次数=10；聚合报告样本只显示10.
2.定时器：
	【吞吐量控制器】：
		Based
			Total Executions:(默认)按百分比分配流量
			percent Executions:代表总次数
	【固定定时器】：
	
	
	
3.集合点：jmeter叫做同步定时器，用于实现并发;位置：线程组-添加-定时器-Synehronising Timer【同步定时器】

达到设置数量后才会发送数据

4.简单的压一压：
线程数：虚拟用户数100
Ramp-UP:多久加载完虚拟用户数。20
循环次数：3
每个接口的总请求：100*3=300个

二、安装插件
安装插件工具下载jmeter-plugins-manager-1.9.jar放到jmeter/lib/ext文件中
	插件下载地址：https://jmeter-plugins.org/downloads/all/

小蝴蝶中下载：
JMeterPlugins-Extras.jar,
jmeter-plugins-manager-1.4.jar,
JMeterPlugins-Standard.jar

PerfMon Metrics Collector使用原理：
1.需要在服务器安装一个ServerAgent.zip，用于收集服务器的性能参数。
然后通过4444端口输出
2.在PerfMon Metrics Collector组件中通过4444端口区捕获服务器性能参数。

linux上传ServerAgent.zip
在Linux中进入任意一个目录
cd /xxx 到该目录下
rz 上传包命令
mkdir ServerAgent 创建文件夹
unzip ServerAgent.zip -d ServerAgent 解压ServerAgent.zip到指定文件夹ServerAgent中
cd ServerAgent 进入文件夹
ls  后可以看到startAgent.sh这是Linux中的启动
chmod 777 startAgent.sh 给startAgent.sh一个可执行权限
sh startAgent.sh & 启动startAgent.sh 其中&的意思是在后台运行
当启动后出现Binding TCP to 4444说明服务启动成功
systemctl stop firewalld.service 然后关闭防火墙

然后在jmeter中监听器PerfMon Metrics Collector启用
点击Add Row :Host/ip 输入服务器ip，端口port：4444，在Metric to collect中选择你要看cpu还是内存Memory
然后点击启动蓝色按钮，就可以看到检测服务器的监控图了。
监控图的作用主要是：
1.看趋势，找性能拐点
2.写性能测试报告

三、实际性能压测的场景设置
场景：性能测试用例
1.旧系统来自于运维
2.新系统来自于合理的预估
	按场景预估和规矩预估;做OA，总用户10000个，测试打开功能做并发，8：30-9：00打开比较多
	按照2/8原则：半个小时并发8000个人，8000/1800=4.44约等于5，最多50并发
	一般大部分公司很难超过500.5000以上、1万、十万一定要集群

服务器（集群）和压力机（集群）
 1.但接口基准测试：使用一个用户测试接口5min。
 目的：为了在没有任何压力的情况下：查看各项性能指标。
 每个项目关注的数据都是不一样的
 cpu内存、网络磁盘、tps响应时间，除了这些还有一些如下图所示：
 图
 一般就这些
 
 2.单接口负载测试场景：
 （测试计划和方案一般会写在一起，上面是计划下面是方案
 测试计划：是人员测试的安排
 测试方案：怎么测，关注哪些指标，用什么工具去测。）
 通过逐渐的对一个接口进行施压直到出现性能拐点。（这个拐点不是指其中的一块，有可能是CPU的、     中间件、数据库、慢查询锁表等，只要有任何一个地方出现拐点，我们就会把他记录下来，最大的并发量就在这里确定了）获得被测接口的最大处理能力以及相关的性能指标
 
 3.混合负载压测场景;(不是只有一个场景，有多个，在同步定时器集合点中设置并发量)
 目的是为了验证整个业务的最大的最右性能提现。终端在于模型的设计。模型来自于数据，来自于生产环境的日志，或者产品经理给的
 怎么做:用什么
 1.递增式线程组，共进式线程组：用的最多的
 2.极限线程组：用来做极限测试或者浪涌测试
 图
 压测策略，压测场景，压测用力
 图21
 This group will start：启动多少个线程数
 
 First，wait for:等待多少秒开始压测，一般为0
 
 Then start；一开始有多少个线程数，一般为0
 =================================
 Next add
 threads every
 using ramp-up
 每多少秒启动多少个虚拟用户数，每组数据持续运行多少秒
  =================================
Then hold load for 60：当你把虚拟用户数都加满之后负载运行多久
4-24小时：一般是8小时，可以是4、8、12、24小时用来做持续不断的压力测试
  =================================
Finaliy stiop
threads every
每一秒停止5个虚拟用户数。

3.压力测试场景:
验证系统的极限。直到有任何一个性能指标超出预期。

4.稳定性测试场景。
在压力测试下持续运行4-24小时。

五、无界面压测
理论–》指标–》压测脚本–》脚本完善和增强–》模拟真是场景–》压测场景–》监控平台-》平静定位和性能调优
当我们走到压测场景的时候，就开始压测，我们不是使用的jmeter压测，我们使用的是无界面压测
为什么要用无界面：
1.节约资源
2.更快捷，只需要启动命令即可进行压测
3.主要适用于性能压测集成

-n 表示无界面压测
-t 指定你的jmx脚本
-l 生成测试报告
注意：生成jtl报告的需要做一个配置，在jmeter目录/bin/jmeter.properties文件
要改3个地方：下面的复制一份改
1.将保留文件改成xml
找到jmeter.save.saveservice.output format=csv
将csv改成xml
jmeter.save.saveservice.output format=xml
2.将保留他的响应数据
找到jmeter.save.saveservice.response_data=false
将false改成true

3.保留他的请求数据
	找到jmeter.save.saveservice.samplerData=true
	将false改成true
如果更改之前你打开黑窗口，关闭后重新在jmx文件出打开cmd，不然不会生效

命令：jmeter -n -t test.jmx -l resoult001.jtl


直接生成html报告：
-e -o
命令：jmeter -n -t test.jmx -l result001.jtl -e -o reports
注意：生成html报告的话需要将上述
	jmeter.save.saveservice.output format=xml
	再改成csv
	jmeter.save.saveservice.output format=csv
	
很重要的两个参数：用于分布式集群压测
-r :表示启动所有的远程压力机执行压测
-R ：表示特定的远程压力机执行压测，多台使用逗号,隔开
jmeter可以看到有几台远程集群机器：jmeter-运行-远程启动-可以看到有几台压力机
如：192.168.0.1：1002,192.168.0.2：1003,192.168.0.3：1004
命令：
jmeter -n -t test.jmx -l result001.jtl -e -o reports -r 启动所有压力机
jmeter -n -t test.jmx -l result001.jtl -e -o reports -R 192.168.0.1：1002,192.168.0.2：1003 启动指定压力机

jmeter内存溢出解决：要找到jmeter目录/bin/jmeter.bat文件
找到
if not defined HEAP(
set HEAP=-Xms1g -Xms1g -XX:MaxMetaspaceSize=256m
)
将HEAP=后面的两个-Xms后面改成1g就可以了，就不会溢出了

=第三讲=
1.Linux服务器性能分析命令及详解
2.Garafana+influxDB监控jmeter数据
3.Garafana+Prometheus监控服务器和数据库性能
4.性能瓶颈分析以及性能调优方案详解

一、无界面压测时，
top
load average:平均负载
htop

二、Garafana监控平台
传统项目：centos+php+mysql+nginx
1.无界面压测中如何实时的监控。
Garafana：监控平台
influxDB：实时数据库
Garafana+influxDB+jmeter组合
优点：
1.实时
2.美观
3.能够存储和对比
原理：
1.运行jmeter时会把数据写入到influxdb
2.influxdb实时存储执行结果
3.grafana连接influxdb，将他的数据展示为图标。

2.安装influxdb以及部署
	(1)下载并且解压
	
	(2)修改配置文件
	
	(3)启动infludb的服务：influxd --config influxdb.conf
	
	(4)使用influxdb创建jmeter数据库
	
3.在jmeter脚本中增加后端监听器：作用是连接到influxdb

4.执行无界面压测，并查看jmeter数据库中是否有数据
select * from jmeter

5.安装grafana,并从influxdb抽取数据并且通过仪表盘实时展示
https://grafana.com/grafana/download


2.无界面压测中如何监控服务器。
3.无界面压测中如何监控数据库。
4.redis、jvm、mq...都是需要监控起来，以便发现瓶颈

三、性能瓶颈分析和性能调优
(1)基准测试
一般是单接口（单交易）：使用一个用持续压测1min以上。
目的：获取单个接口没有压力的情况下各项性能指标，作为他场景的参考依据。
核心性能指标：并发用户数，响应时间（<1.5s），吞吐量（TPS、QPS、RPS）,资源利用率（<80%），事务错误率（<0.1%）

(2)负载测试【一般在10分钟左右】
单交易负载测试：单个接口
多交易负载测试：多个接口、流程接口（流程负载测试、混合负载测试）

为什么做负载：就是为了得到下面两个指标
最佳并发用户数：资源利用率最高
最大并大用户数：并发用户数的上限，一旦超过上限，那么相应时间用户无法容忍5s，TPS直线下降

(3)压力测试【一般一小时为单位，如8、10、12、24h，有最长的压一个星期】
破坏性压力测试：(极限测试)：最大并发用户数，可能会伴随客回复性测试(单机、集群)
稳定性压力测试：最佳并发用户数

(4)浪涌测试

(5)容量测试
第一种:TPS容量
如：测试被测系统是否能够每秒处理1000个事务
第二种：并发用户数容量
如：测试被测系统某一个功能是否能够支持1000个并发
第三种：在线用户数
如：测试被测系统能否支持10000个用户使用。（压力不大）
思考时间:吞吐量控制器
上面3中场景我们应该怎么去做，用例怎么去设计？

二、实战
常规的场景线程组就够了
线程组
图
线程数：虚拟用户数：100
Ramp-UP时间：10 10s加载100个用户，平均每秒加载10个
循环次数： 1 永久：一直跑
调度器：
持续时间：10 如果超过这个时间还在一直跑，那么请使用CLI模式，也就是命令行模式
【持续时间优先级大于循环次数】
图
谁占的资源最多
场景一:
线程数10，Ramp-UP:1,循环次数：2，每次占用10个资源内存， 1
线程数20，Ramp-UP:1,循环次数：1，每次占用20个资源内存， 2 占的最多

场景二:
线程数：1，Ramp-UP:1 循环次数：永久。持续时间：10s
问题：请问这里请求了多少次？这里的请求和设置没有直接关系

以上两个场景对应结论：
1.要吗就是固定循环次数，这个时候你设置持续时间没有意义
2.要吗就是循环次数设置为永久，然后固定持续时间

实战一：


场景9	总和业务，从投产到入库	50~100个用户并发数5的情况，持续运行1个消失	持续运行，观察通过的事务和响应时间

依据上述场景，我们看一下下面做法是否正确:
线程数：50~100，Ramp-UP:1,循环次数：永久，持续时间：30s

聚合报告：
标准差主要是看：平均值和90%百分位之间的差由上图可以看出标准差还是很大的
吞吐量：就是TPS
接收KB/Sec、发送KB/Sec其实就是吞吐率

实战二：
以TPS（每秒完成的事务数）为10的压力持续压测30s？
目标：设100，每秒处理100事务
加载时间：达到目标想要多长时间：3
加载次数：递增次数，加载几次:3
持续运行多久：60

如：测试被测系统某一个功能是否能够支持1000个并发
方案一：1000宪曾+同步定时器得到核心的五个性能指标（(1)基准测试中五个）

bzm - Arrivals Thread Group到达线程组：的目标是TPS目标
bzm - Concurrency Thread Groupbzm-并发线程组：的目标是并发数目标
两种页面及其相似，但是目标不一样。
具体表现在聚合报告中，右上方的启用的线程多少不一样，TPS吞吐量不一样。
方案二：
TPS图
相应时间图
活跃线程数图
jp@gc - Active Threads Over Time jp@gc-随时间推移的活动线程
jp@gc - Transactions per Second jp@gc-每秒事务数
jp@gc - Response Times Over Time jp@gc-随时间推移的响应时间

实战四：递增式场景
场景“比如你的线程数多一次性加载不完，实际中也是慢慢加载的，这种情况下就使用递增式。
一般使用的是递增式

实战五：混合场景

==============================
一、项目实战场景：
读书屋网站要推广了
高峰时期预计1000/s登录【线上监控；同类型项目并发量】
不知道系统能不能撑住【找出最大峰值;要用负载测试】
生产环境 8核8G
性能测试环境 2核2G

二、性能需求分析
1.典型的场景：找出系统的负载能力
1.负载测试
2.模拟1000/s请求，压系统
2.如何定义线程数
1.具体使用什么工具不要紧–能够模拟出性能场景就行
2.理论计算模型=并发量到线程数
3.先做一次基准测试
基准测试目的：就是获取单线程的响应时间：10ms；计算线程数量
4.单线程并发数： 1000ms/10ms【接口响应时间】=100次/s
5.线程数量：总的并发数/单线程并发能力：1.理论线程数量：10个 2.就可以模拟出1000/s并发