相对并发和绝对并发；相对并发是指在一个时间段内发生的事务（可理解跟tps挂钩），绝对并发是指在同一时刻发生的事情（可理解为跟线程数挂钩，jmeter的“集合点”功能可以实现这种方式）
40%---测试分析
30%--执行测试-通过工具模拟性能场景
30%--测试结果分析
指标
QPS查询请求----get
TPS事务请求---post
RT响应时间---用户体验
并发处理能力---系统不崩溃的情况下能同时处理的最大事务
资源占有率--成本最少、吞吐量最大、最小响应时间
实操
测试场景
TPS 平均值要求、峰值要求
二八原则计算（指80%的业务量在20%的时间里完成，另此公式不一定适合所有项目，具体需要结合每个系统项目应用场景）
全链路压测
链路-用户请求之后服务器后端处理流程经过了多个系统节点
产生原因
系统越来越复杂，催生出来
系统复杂度 ---【分布式微服务、中间件、集群、缓存、异步架构、分库分表】
01 分布式微服务架构-----（springcloud dubbo）将一个大系统分为多个子系统
系统业务功能越多、代码多，可维护性下降--大系统分开
每个子系统--独立代码管理、独立运行部署
对于测试人员--的影响
全链路日志测试报错 先看日志，微服务多个系统怎么看？
日志监控平台---ELK（收集所有日志）大项目看日志平台
错误日志太多，全链路追踪（skywalkin），每个接口调用信息 和调用对象都会有
全链路资源监控
普罗米修斯+grafana
nmon 监控服务器资源
02 中间件
需求变多 引入中间件
1、集群架构---增加了一个链路节点
一个服务器不够用，多个服务器部署统一项目 组成集群。
一个请求不是直接到后端程序，要经过负载均衡中间件。
负载均衡 nginx 分配到多个服务器做集群
2、缓存架构---数据库性能差，将经常访问的高并接口数据缓存起来
Redis--也有性能瓶颈
性能测试---最忌讳，只测不调优
压测流程
1、性能场景分析与创建
1.1压测场景
业务峰值稳定性
大型活动等峰值业务稳定性考验
新系统上线
准确知道站点的能力，防止系统一上线被打垮
技术升级验证
技术架构升级后进行性能评估
容量规划
对站点进行精细化容量规划，利用压测来为系统扩容，性能优化提供数据参考，节省成本投入，提高资源利用率
性能探测--单接口压测
探测系统的性能瓶颈，进行针对性优化
1.2压测策略
负载测试
系统在不同负载下的性能表现，发现性能拐点，找到系统最佳性能 举例：递增压测
压力测试
评估系统在接近预期负载或超过的情况下的运行状况，同时关注负载减小后的自我恢复能力 举例：高并发开头，逐级递减负载
基准测试
通过基准测试建立一个已知的性能水平（基准线），当系统软硬件变化后在进行一次基准测试记录 举例：对项目的脚手架进行压测 得到基准
配置测试
不断调整系统配置，以达到最优解
稳定性测试
在特定的负载下，持续施压，看能否稳定运行
1.3系统架构梳理（分析风险点）
端到端的请求链路
技术架构
分层结构
模块划分
数据库、缓存、消息队列等中间件使用
1.4压测内容
关键业务接口
访问量大接口
1.5压测方案编写
背景和目的
业务和技术指标
设计范围和链路（需要和涉及的各团队一一对齐）
压测实施里程碑（每轮呀猜测的模板和要做的事）
压测任务及进度（整体压测任务拆分以及当前进度，提前评估风险）
压测模型和策略（类似测试用例）
2、压测脚本编写及调试
一定要有断言，不然只会判断相应是否200
调试
仅一次控制器、同步定时器：保证并发
查看结果树
调试取样器
中间变量在结果树种体现
JEMTER日志
用表格查看结果
插件
fiddler或charls+Proxifier
调试不通的时候，就在接口上的高级选项种 写代理服务器 本机地址，去fiddle抓包看接口信息
3、脚本执行
分布式压测
带宽影响、分布式需要多台机器，一台master机 分布式发送脚本运行压测。
空接口试压
4、指标监控
业务指标
如并发用户数 tps 成功率 响应时间
硬件指标
如cpu利用率 内存 磁盘io 网络io
软件指标
线程池、jdbc连接池 JVM（GC/FULL GC/堆大小） 效率低下SQL 锁等待/死锁 缓存命中
工具介绍
grafana----展示数据 前端工具，用于访问influxDB,自定义报表 图表
influxDB-----工具 通过jmeter后端监听器设置
普鲁米修斯配置 插件
5、定位瓶颈
保证压测流量全部进入后端
1、网络接入层（waf slb cdn）网络接入层由于带宽、最大连接数
2、单ip地址限流
3、slb自动伸缩失败，负载均衡失败
4、nginx机器性能受限
5、限流熔断降级
6、施压机性能瓶颈
硬件相关指标，深入分析
1、cpu高：top命令查看占用最高，利用pid查该线程，如果是java应用，用jstack看该线程执行的堆栈，看资源消耗在哪个方法，再查看方法源代码
2、内存高：看某个进程占用高，是否有大量swap（虚拟内存交换）
3、磁盘io高：通过减少日志输出、异步或速度快的磁盘来降低，也与数据库写入复杂度相关
4、网络io高：考虑传输报文内容大小，不超过硬件网络传输70%，通过压缩报文、本地缓存以及多次传输提高网络io
软件相关指标，深入分析
1、JVM
Java虚拟机，帮助java在不同平台无需编译即可运行。通过在虚拟机上生成字节码，由字节码在不同的平台上解释成机器语言来运行。
一般对象在新生代的eden区生成，大对象：如数组和长字符则在老年代产生/存活时间较长的对象也会到老年代中去。
虚拟机提供了一个 -XX:PretenureSize 参数，如果对象大于这个设置的值就直接在老年代分配。
当eden达到一定比例后，会young GC，清理无用对象，剩余对象会逐步（默认清理15次）往老年代方向储存。
full GC：造成stw（stop the world）过长，相对minor GC 慢十倍以上
产生原因：1、使用 system.gc() 容易产生。可以通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。
2、 若老年代空闲空间小于新生代存在对象空间，会查看参数 HandlePromotionFailure 是否被设置成了允许担保失败，如果不允许则直接触发Full GC；如果允许，那么会进一步检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果小于也会触发 Full GC
3、Metaspace（元空间）在空间不足时会进行扩容，当扩容到了-XX:MetaspaceSize 参数的指定值时，也会触发FGC
old GC：
产生原因：1、minor GC 后进入老年代的对象大于老年代的内存大小
2、minor GC后剩余对象过多，大于老年代
mixde GC：老年代内存占用45以上，触发，对新生代和老年代进行回收。
2、cpu占用和负载
2.1 cpu占用率为实时的占用率
2.2 cpu负载为一段时间的平均占用率，包括等待的进程
3、线程池
线程池不足：增加线程，了解为什么线层阻塞
4、连接池
增加连接数，了解为什么连接未释放原因
5、数据库指标
慢查询sql、命中率、锁、参数设置
算法、缓冲、缓存、同步或异步
6、性能调优
6.1、性能调优后，需进行回归测试
6.2、时空转换
6.2.1、时间换空间
通过增加耗时来减少空间的消耗
6.2.2、空间换时间
cdn
6.3 提前处理
通过预先处理数据或存储，减少下次读取数据的步骤耗时
6.4、
7、输出测试报告
####
####
####
