性能名次解释
1、用1个用户（几乎毫无压力）访问服务器，观察项目的基本性能
2、单场景（单接口-基准测试）
目的1：最大处理能力 压力测试 关注结果
目的2：评估接口的性能 负载测试 关注过程 一点点增加用户数
3、混合测试（容量测试）
目的3：基本性能如何 性能测试
4、稳定测试
基于混合+固定用户数+时间长
吞吐量
可以衡量服务器的处理能力的都代表为吞吐量，如tps、hps、网络
针对服务器的测试
压测技术：
并发：线程（loadrunner、jmeter）、协程（locust）
业务层面的用户（人） 不等价于 工具层面的用户（线程），线程要快很多
业务层面的用户转换成工具层面的用户
1000个人相当于多少个线程？
压测目标
访问日志：
web服务器–nginx/httpd/iis—》日志文件
logExpert–分析日志 找到高峰时段的数据进行分析
pv量–打开一次页面（接口）记录一次pv，一次pv会产生多个hits
运维（真实访问）：首页的pv量是100000，时间范围一天（24小时），高峰2小时：60000
tps–transaction(pv)：1tps=1pv
期望首页tps指标：60000/7200（2小时）
单场景（基准测试）：tps最低要求达到60000/7200（2小时），最低能达到混合场景的tps
通过上图，页面访问(pv)排名，很容易算出业务的百分比（总pv量/单页面的pv量）
真实用户（在线）–cu vs 虚拟用户–vu（线程）-》本质区别就是会话时间不同
下单业务
响应时间：RT=1s
思考时间：Tt=9s
CU：RT+Tt，完成一笔业务需要10s
VU：RT，完成一笔业务需要1s
一分钟时间：
1个CU：6笔业务
1个VU：60笔业务
如果让CU达到1分钟60笔业务，请问需要多少个CU？10个CU
结论：1个VU相当于10个CU
CU = （RT+Tt）/RTVU 转换在线用户公式
推倒过程：
1/RT+Tt：10s完成1笔，1s完成10/1笔
1/RT：1s完成1笔
CU（1/RT+Tt） = VU*（1/RT）：VU与CU吞吐量相等
CU/（RT+Tt）=VU/RT
CU=VU*（RT+Tt）/RT
计算出真实用户的难点：Tt时间
监控网络
服务器与客户端分别下载iperf软件
服务器端输入iperf -s 启动监听服务
客户端cmd下输入iperf -c 服务器地址
客户端到服务器大概是10Mbit =>10/8 实际下载速度1Mbit
如何算是否带宽够用？
jmeter在客户端上跑一下，设置1个线程，如下图显示153/kb，吞吐量是5.6/s
瓶颈分析
资源消耗过低，吞吐量上不去
压力机：
配置：如jmeter压测工具，主要是内存方面，毕竟是java开发的软件，容易造成内存泄漏问题
压力工具：针对IO比较大的，jmeter的吞吐量就比locust小
资源消耗过高，吞吐量上不去（常见但不好定位）
压测工具选择
Jmeter、Locust、Loundrunner
并不是说线程的效率一定比协程高，主要看项目里有没有I/O的出现（网络I/O或磁盘读写I/O），因为有I/O出现的时候，线程会经常被阻塞的，cpu认为它还是个资源，需要进行上下文切换。
总结：在受I/O（网络I/O或磁盘读写I/O）因素影响较小的情况下：三个工具的压测结果相近
在I/O因素影响较大的情况下，Locust、Loundrunner压测结果更好
举例：例如有10客户同时去银行办业务，客户手里资料准备齐全，营业员不需要等待客户这边处理的事情，这种情况派10个营业员去接待10个客户效率是高的（线程模式，没有I/O阻塞的情况）。
假如业务员需要等待客户大量的准备资料时间，派10个业务员去接待客户，大部分营业员都是在等待，需要大量的上下文切换，占用资源。
