性能测试的底层逻辑
- 程序为什么会有性能问题
用户操作 客户端（web/app/小程序）触发网络请求，服务器处理大量网络请求代码运行需要大量服务器资源（CPU、内存、网络、磁盘等等）
资源不是无限，硬件配置不是随意变动。
大量请求带来资源消耗大于服务器资源，就出现性能问题（响应慢、报错、...）
- 性能测试的目标是什么?
通过模拟出大量用户使用的情况，分析程序的反应（响应时间、吞吐量、是否报错...）
- 如何模拟性能场景（这次目标）
要性能测试，先做接口分析
压测目标场景涉及的接口
性能之前先测接口
借住工具去发起大量请求-Jmeter
一人一双手，无法模拟大量请求。
如何模拟多个用户操作的场景
- 借助工具 发起 海量的网络请求(jmeter、loadrunner、k6、Locust..)
- 线程(虚拟人)-操作系统底层去执行一个任务的最小单位
- 线程组配置:
线程数量: 申请多少线程来为你工作
Ramp-Up时间(秒):线程就绪的时间(多久时间让线程就绪)
循环次数:
输入数字: 线程执行的任务的次数
永远:一直干活不停，干完一次就下一次
调度器:持续时间-测试的时间长短
1.线程各干各的(单个线程的角度，干活的顺序就是你定义的先后顺序)
2.如果制定了循环次数: 线程执行完指定的次数后，线程结束
3.如果指定了持续时间: 时间一到，线程陆续停止干活
线程数量如何确定
考题1：每秒20个请求，持续至少30秒钟
方案1：20线程，持续30秒，循环次数：永久
结果：30秒左右--请求了800 每秒27.8
方案2：600线程，持续30秒，Ramp-Up:30秒，循环次数：1
结果：正确
- 样本数: 压测过程中jmeter发起的总请求数
- 响应时间: 系统在 指定的压力状态下，能否及时响应用户请求
- 吞吐量: 每秒处理的请求数量
方案3：20线程，持续30秒，循环次数：永久+ 定时器
相比较方案2：不需要频繁的创建线程和销毁线程，节约jmeter所在服务器的压力
下面表示 每60秒采样60次
工作中经常碰到场景1:领导(架构师)直接说 测一下系统能不能支撑 4000/s 请求
方案2思路: 总共:172,800,000 个线程、分为43,200秒（12小时）启动(不建议)
弊端: 每秒都会有 4000个线程被创建和销毁，极度消耗jmeter所在机器的CPU资源。(可能导致运行jmetgr的机器就卡住了)
方案3思路:4000个线程，每秒种发起一次请求，持续指定的时间。
弊端：一个电脑上运行大量的线程，可能导致电脑卡顿，从而达不到想要的并发压力
Jmeter分布式集群压测
通过 多台机器 同时执行 性能压测脚本，模拟更大的并发压力
1.多个独立环境，运行jmeter 
2.执行机 环境搭建与启动
3.控制机 修改配置文件重启jmeter
远程启动
4000个线程 有2个服务器 每个服务器就运行2000个
学习可参考：jmeter分布式集群压测_jmeter集群压测-CSDN博客
