性能测试环境:
操作系统--生产环境常用的 Linux (CentOS 7)
无版权费，最小内核运行(长时间运行的特质)
理论上：本机可以运行项目，如果是学习，可以在windows上测
有条件的尽量去装 虚拟机 MAC电脑 芯片M1 M2 （最好自己去买个阿里云）
环境配置：如果实际工作做性能测试 ，硬件型号 尽量一致（与生产环境一致）
服务器数量： 集群环境下，不可能给我们同样环境，类推：1台服务器，承载1000/s
数据准备：数据库的导出与备份。
会以SQL语句的形式，存放起来.
复制SQL，直接在数据库运行即可
面试题： 如果你在性能测试，测完之后脏数据怎么办？
用代码去生成 我们需要的测试数据
数据的技巧： 1.基于已有数据衍生 2. 随机生成
注意： 数据的状态分布 比如：造订单数据 --多种状态 尽量贴合生产环境
数据分布 决定了我们的数据库层面执行性能.
测试工具--Jmeter
第三方插件 -- 课后资料
放的位置在 jmeter文件夹下\lib\ext
线程：多线程--很多个虚拟人(用户) 同时干活
jmeter的执行流程，单线程下，是有序的 从上到下一个个执行
多个线程会同时执行
测试结果查询:
汇总报告
聚合报告
Transactions per Second 每秒事务处理量
Response Times Over Time 随时间变化的响应
Active Threads Over Time 随时间变化的活动线程
初级阶段，活用这五个东西基本就能够帮助我们找到对应的性能瓶颈了。
后续我们还会讲其他的东西
前两个： 可以看到最终结果
后面三个： 可以帮助我们看到对应的过程
基准测试:
收集系统在1个线程中的性能基线 .
为什么 线程数 是1
对线程数要求： 1是最小单位 系统100%一定能承载
推论：
假设：基准测试 1线程 吞吐量是 100, 希望 10000的吞吐量 我只要准备100个线程就够了.
假设2：1线程，模拟了并发量是 40/s 如果要模拟 4000个并发， 只需要准备100个线程
给自己一个计算/规划的 线索和逻辑
负载测试：
是为了发现程序系统的实际处理能力 -- 梯度压测
三个阶段
第一阶段： 并发增加 -- 吞吐量增加 (正向提升)
第二阶段： 并发增加 -- 吞吐量不再上升，响应逐渐变长 (系统处理不过来，新的请求等待、积压状态)
第三阶段：崩溃--并发增加 (吞吐量下降,资源不够用)
以上是比较乐观的场景！
极端情况--第二阶段直接跳过，发生在服务器配置太差,错误率快速上升。 吞吐量--持续上升!
为什么会上升？ --因为请求已经不执行了，直接报错了。所以返回速度很快!
实际场景：
如果要做性能，这种情况下，我们极有可能是需要有一个流程的！
把多个接口放到一个线程组不就行了？
那如果某一个接口报错，从而出现了一些问题呢？
事务的问题：
一个流程下，要么一起成功，要么一起失败(因程序异常导致的失败). 这种情况就叫事务
转账：用户A -- 用户B 转5000元 在计算机流程：用户A 账户 -5000 用户B 账户+5000
有情况 用户A -5000 成功 用户B +5000 失败 一起操作不成功.
jmeter的事务控制器
右键-->逻辑控制器 -- >事务控制器
多接口怎么来？
如果有文档--按文档顺序操作 ,没有文档。
我们可以用脚本录制的方式找到多个接口 jmeter提供了这个功能
脚本录制：
测试计划-->非测试元件--> HTTP代理服务器
点击启动，进入录制模式
本机代理模式启动 -- 让我电脑的所有请求，都从18001走.
windows系统，打开设置,左上角搜索代理
一定记得点保存！！！！
证书相关是HTTPS请求，需要安装证书.证书安装，找到你的那个请求IP地址，下载证书，在pc端双击一下，就可以安装了。
开启代理--不要用谷歌浏览器! 因为谷歌浏览器很多情况下会自带代理
吞吐量控制器：
流量控制用： 网络资源分配. 保证网络的稳定性和公平性
Total Executions 总数模式： 在测试期间去限制请求的总次数， 测试时间是 1分钟 总请求次数是120 均匀的发送请求。1秒2次.
Percent Executions ： 百分比模式：根据采样器执行册数的百分比来发送。 比如：我设置了首页是50 ，那么这个情况下他会占用总请求的次数的百分之50
评论区