性能测试环境:
操作系统 -- 生产环境常用的 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
评论区