下面开始学习性能，第一天，目的要了解性能测试的基础
什么是性能测试？？？？？？？？？？？
用工具模拟实际并发场景，发现系统问题，使系统上线后在接近的用户场景下不死。
具体解释？？
工程解释：
性能测试是针对系统的性能指标，建⽴性能测试模型，制定性能测试⽅案，制定监控策略，在场景条件之下执⾏性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满⾜既定值。
你在工作中经常做得三件事？？？？？？？？？？也叫性能测试的价值
分类：
1. 性能验证：针对给定的指标，只做性能验证
2. 性能测试：针对给定的系统做全面的性能测试，可以得到系
统的最大容量，但不涉及到调优 –-旧系统保证系统不衰减
3. 性能测试+性能调优：针对给定的系统做全面的性能测试，
同时将系统调整到“最优”状态
意义：
- 验证系统上线之后是否可以稳定运行 第一层的含义
- 给出开发和运维人员提出线上的配置建议 第二层的含义
- 在满足业务要求的前提下，可以节省资源 第三层的含义
让你压几百，你就压，压了500个没有崩溃这种方法叫性能验证 一般性能都这么测试
10000 并发正常,40000万开始增加，50000并发满了 ，最大6万就崩了 一般的性能测试
一边压测，一边调整，各方面配置都很优秀，这就是性能调优的过程
一般在公司你就做，第一步第二步
常用性能测试的性能指标？
RT 响应时间 最重要指标（点一下页面按钮，到页面完成出来这就叫响应时间，包含前端点击，点击之后给接口发一个请求，页面返回的内容渲染在页面）
如果只看发到服务器的服务器的处理时间也叫rt根据具体事件定义
HPS 每秒点击数 ，f12加载好多页面，点击一次请求一次没啥价值
tps 每秒处理事务处（什么是事务？刚才的请求返回叫事务？可以，站在服务器角度收到给响应当一个事务？可行,数据库接到一个查询发出去？事务?也可以 ）
qps MySQL ，每秒收到的请求，把你的tps定义到数据库中就是qbs ，你调用接口只发一个数据库查询？可能不是1可能是10，当你把数据库查询当tps就是，你单测试数据库那就是tps，或者以数据库收到查询为主也等于tps
cps 请求页面返回的
pv 用户访问量 一天访问10000次 最大 都是1s 10000 最小 10000/24均分 跟性能没关系帮助你算并发
有时间，时间段访问高。按公司来，比如十分钟二百次，200/10*60 这个接近最大峰值 ，提供的数据越详细我的设计就越细
uv 独立访问者
注意：pv,uv这两个是用来帮助你算tps的 只给你每天的用户访问10000 每秒的tps=10000/24*60*60=0.115 想要接近真实就要有更详细的数据
找到每个时间端访问的最大值 比如今年某个十分钟二百次最多访问，200/10*60 这个接近最大峰值 ，提供的数据越详细我的设计就越细
吞吐量 每秒处理的数目，吞吐量在jmeter就是tps JMETer报告会带上 吞吐量就等于tps 在Jmeter
出错率 error
对应的资源使用率
总结性能测试只关注四个重要点：响应时间（rt） ,tps每秒处理事务处,错误率，对应的资源使用率，也叫资源使用范围
tps怎么算呢，核心问题必须掌握？？？？？？？？？？？？？？？ 线程，tps，响应时间换算关系
给你500tps 你要配多少线程？没法算你的给我响应时间 ？？？？？？？？？？？？？？？？？？
问题一 接口a RT(响应时间0.2s) TPS(1000TPS) 问多少个线程？？？？？
1s/0.2s=5 1000/5=200
一个线程发5个，达到1000个tps需要开200个线程 ，能不能到1000？ 真正用200个压测测会大于0.2s tps可能到不了1000tps 要梯度加压 ，最终给的200可能大于200
算法：1/5=0.2s 1000/5=200 默认一个线程1s
取决你的响应时间能不能稳定到0.2s,随着你的压力会响应时间变大，如果想达到1000就要加梯度加压
错误率是指你自己加断言的错误率 ？？？？？？？？？？？？
常见的状态吗 200 断言返回code 另外就是数据库去查
场景设计方法？性能指标如何确定？
响应时间长，1秒钟可以0.1s 可以处理10个 0.5 tps就会下降，一秒钟处理两个 也就是说你的tp响应时间增高，你的tps就会下降
客户端 -负载均衡 -应用-缓存数据库-数据库持久化
2. 如何在不同的阶段，定义TPS呢？
每秒钟服务端成功处理的事务数。
队列作用（消除峰值，100个人请求，让他排队，压力小很多）
处理异步，以前没有队列，把请求给服务器，不是马上返回，处理，先给用户一个处理结果，会把你的事放到队列里面
例子
登录和下单的测试 ，为什么分别测试要组合一起测试？
贴近真实用户场景
登录接口 测试 单交易压测
下单接口 测试
登录-下单 测试 混合场景
性能测试先做单交易在测试混合场景 ，首先清除单独业务的响应时间和大体的情况
测试前期要在服务器内网压测！！！！！！！！！！！！！！！！！！！！！！！！！也就是说你的服务器是11，你要在这个网络内找一台机器去压他
举例子几个性能测试指标 第一 指标怎么定的？？？要具体算出来
tps肯定能到100笔每秒，无非就是加压，还有个响应时间的基本要求 响应时间要求小于5s
第二设计场景
1，验证被测场景是否满足目标tps
2，验证被测场景最大支持的tps，找到拐点
第一个tps 1s83个 就是开83个线程 持续时间一小时 看tps是否符合
第二个就是如果第一个不够的话，就加服务器，开发该配置，然后够的话就继续压，看tps最大到多少下降找到拐点，同事还要考虑tps的响应时间是否在范围内
第三
比如：抢火车票，一个人测试没问题，多个人用的时候会引发问题？为什么多个人用会有问题？
代码的问题，有的代码写的死循环？一个人写了慢了点，多个人使用产生很大cpu，死循环占cpu
功能测试就是一个人装一个假肢能装上就行，性能测试看看他使用的效果是不是好用
性能测试是通过自动化的测试工具模拟多种正常 -解析通过工具去模拟
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行 这句话不太科学
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。 负载不断的增加压力
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。找最大容量
进程和线程，线程是通过cpu去调度的，每个线程就是一个用户
响应时间不是你可以控制的
性能指标设计的方法！！！！！！！！！！！！！！！！！！！！
第一种 老系统无历史数据/日志监控/用户分析参考
拍脑袋，压500 压1000 做了也没有意义，其实也有就是性能验证了
根据竞品，参考老系统，你的新系统根据老系统参考测试拿到tps
第二种有上游
有pv 用户访问量 和uv用户量
根据2.8原则来，80%的任务产生 在20%的时间内 ，每个公司业务不一样，有的是1，9，4，6原则
第二---根据业务来 如果你拿到一天一万业务量 最好拿到分钟和小时的，一天的交易总量，就找每小时，看不到就用2.8
1万除以24*3600 这样算出来的是100%
二八算法 8000除以 24*3600*0.2 这样比上面强 没有办法情况下二八原则
也就是说你每天80%的业务量除以20%的业务量，均分到每s ，算出tps
假定一天是10000访问量
不算二百，百分之百业务发生在100%时间 tps很小
二八算法 10000*80% /24*60*60*20% 这样算出来的tps肯定比按天算大
第三：那没给你找个业务一天的uv活跃用户在线数目？？？？？？？
uv活跃用户数，能拿到小时最好，拿不到就乘以3%-5%算出来tps 在根据响应时间算出虚拟用户线程
模拟用户一千个用户如何模拟，根据并法度百分之3%-5%，一千个用户就是30到五十个在线
第四：pv, 只给你每天的用户访问10000????????????????????????
每秒的tps=10000/24*60*60=0.115 想要接近真实就要有更详细的数据
找到每个时间端访问的最大值 比如今年某个十分钟二百次最多访问，200/10*60 这个接近最大峰值 ，提供的数据越详细我的设计就越细
例子让你设计测试场景？？？？？
针对产品查询业务峰值日：10-26，查询全天数据：
登录： 901800 31.8%
产品查询：1184100 41.7%
根据二八原则：1184100*0.8/24*0.2*60*60 = 68.5 TPS 真实的算法
优惠码兑换查询：751200 26.5%
例子2
16:00-16:59 详细数据：
交易总量：633400
登录：178500 28.2% 49.6 TPS
产品查询：352000 55.6% 97.8 TPS 352000/3600s 就是每秒的tps
优惠码兑换查询：102900 16.2% 28.6 TPS
实战 讲解 ？？？算tps 进行压测的流程
先对产品查询接口进行单接口压测 97.8tps设计线程 ，最好拿到平均响应时间 假定给0.2s 大约给20个，不是一下给是一点点梯度加压的
已知上面已经拿到了或者自己算出了tps，拿不到响应时间，先做预热测试，先拿3-5个线程压测十分钟（1.拿到响应时间2.拿到静态下的资源使用情况）
1.先做预热测试，拿响应时间 拿静脉状态下使用情况
2.梯度加压，观察系统加到到目标tps之中过程观察表现
3.继续加压获取最大tps情况也就是别名容量测试，测试完单接口结束后
4.要看你业务的比例进行混合场景压测 ，具体看公司需求讨论是否需要
总结：获取以下场景的 交易数以及各个业务比例分配
场景一：交易峰值日（10-28）交易峰值小时
场景二：交易峰值日（10-28）每个核心业务的峰值小时
场景三：登录业务峰值日(10-25) 核心业务峰值小时
场景四：产品查询业务峰值日(10-26) 核心业务峰值小时
场景五：优惠码兑换业务峰值日(10-27) 核心业务峰值小时
*场景六：普通交易日(10-31) 交易峰值小时
从这三天交易总数和26号这一天的小时数 ，给一个假定的响应时间设计场景？？？？？？？？？？？
能拿到天，就用峰值日
拿不到天就只能平均或者二八
月 天 小时
都是一个道理
总结：性能测试的第一步
单基准测试，也叫单交易基准测试，就是你要起3-5个线程去压测10分钟取出响应时间 ，他是性能测试的重要测试基础步骤
主要看第一
你的脚本配置的对不对，有一种冒烟测试感觉
还有就是这么小的tps看下你的接口和系统能不能正常不报错，如果报错了就不要测试了打回
第二步
获取单交易在无压力的情况下获取基准响应时间和资源使用情况 面试这么说
第三步
初步判断可能成为系统的瓶颈，并决定是否进行后续的测试
问你预热测试怎么回答？？？？？？？？？？
注意 有的公司会问预热测试，严格上和基准测试不是一回事，主要是已经使用的系统，在更新后，使用原有的单交易的tps/s进行测试
性能测试的第二步 单交易（接口）负载场景
1.基准测试完成后，拿到tps和基准测试的rt响应时间 算出 tps算出开多少线程
2.按照梯度加压，运行看响应时间的变化，监控系统资源的使用情况
注意 ，压测过程中tps会一直增加，会停止，停止下会有两种可能（1.线程数到达峰值，tps不上了）
tps涨了，接口响应时间不变
tps下降，响应时间是在增长的 ，对应图片为，注意有峰值tps ，现实项目中这种明显的不是很常见
我们在单压测接口时候要关心的点为
1.目标tps对应的响应时间，这是必须达到的点，这个点时间不能超出我的预期？2.最优tps最优就是系统快要承载的极限?3.最大tps对应的响应时间？
有时候响应时间，短时间先上涨在下降属于正常
一些控制好的系统tps是不会明显的下降的
测试完了单接口要测试混合场景测试
还要考虑性能测试的第三步：多交易混合容量测试--混合场景负载测试
第四步：稳定性性能测试
假如我系统最大支持tps1000
性能测试中的稳定性测试是通过给系统加载一定压力的情况下，运行较长一段时间(8-24小时)，验证系统是否稳定。通常是采用典型混合场景，查看系统运行指数是否平稳。 是否会出现TPS有较大波动、有错误和异常、内存溢出等。
第五步：异常性能测试
性能测试也是存在异常测试的，顾名思义就是在系统异常的情况下看系统的处理能力或者是通过处理后的恢复能力是如何的。
设计用例场景的设计问题？看出26号16：00最大业务一最多
交易峰值小时设计 业务一16：00最高
1.业务交易小时峰值三个业务的最大， 业务一 业务二 业务三 最大交易的小时 ，注意需要做2.8需要确认 进行单接口的压测
2.在来一个最大业务的混合场景的比例进行压测 2.8也要确认
2.交易峰值日天 测试方法和上面一样
已知业务一最大的天是25，但是交易峰值是26，所以要考虑业务一 因为业务1占比例最大，就不用看业务二和三了
比如你要测试25取到交易峰值小时 最繁忙的那个小时单测试和混合
混合场景来一次
单目标tps也就是小时最大 来一次
还有业务二和业务三反正就是这个意思
一、 性能测试场景设计 压多少根据同1s,累计？
500并发 每秒钟500用户同时访问
进程、线程
性能测试指标
jmeter 吞吐量=tps
rt 响应时间
错误率
tps 吞吐量 ，事务数
资源使用率
单接口 预热测试
1.拿响应时间 拿静脉状态下使用情况
2.梯度加压，观察系统到目标之中过程观察表现
3.继续加压获取最大tps情况也就是容量测试
混合场景测试
比较贴近真实
怎么根据数据过度设计
最大tps -对应响应时间
最优tps-往后开始缓慢
目标tps-对应响应时间
经典问题
如何做性能测试？？？？？？？？？？
1.先问什么操作系统？需不需要自己搭建部署 ？
2.问下需要做性能验证和性能整体流程测试？
性能验证,开多少线程，直接压测看看崩不崩溃就行
3.问下能给到什么数据，设计测试场景，能给到天，小时峰值最好，不能精确自己用2.8法则算，或者根据访问总量pv 2.8算或者根据Uv活跃在线数*3%-5% 算tps
考虑单接口和混合场景进行梯度加压
4.问下性能测试指标四要素 tps 响应时间，资源使用率和容错率
5.先对每个接口进行一遍性能基准测试-没问题继续，有问题打回，算出接口平均响应时间
6.正常进行压测，边压边看，在保证正常tps和响应时间正常的情况后，继续压测拿到拐点，也就是单接口和混合场景的容量
7.对于一些需要调优的点，分析和开发沟通辅助定位
8.性能测试完毕出测试报告
接口响应时间约束开发（2-5-8原则）