- 性能测试流程
- 性能测试准备
- 需求分析：鉴别需求的目的，目标
- 业务要熟悉：功能，架构，环境
- 测试计划：什么人，在什么时间，做什么事情，工作量评估
- 性能测试的时间 ~= (1.5~2.5倍）的功能测试时间
- 功能测试的时间 ~= 1/3 （前后端+算法）开发的时间
- 测试用例编写（测试场景设计）--文档
- 性能测试环境搭建（服务环境+监控环境）
-
性能环境（申请硬件）------ 时间悠长，看公司配不配合了
-
中间件搭建 ，你要拿到这些部件 核心参数------可以请人帮忙
-
监控环境 ------尽可能自己搭建
-
- 性能脚本开发
- 脚本协议（脚本、工具）
- 工具 -----jmeter
- 调试、试运行
- 什么时候可以开展性能测试？
- 需求接口测试完成，就可以做性能测试
- 性能测试 ===>执行时间非常长
- 性能场景设计（负载测试、性能测试)
- 执行 + 监控开启
- 通过监控数据，进行初步数据分析
- 性能分析，是需要有监控数据做支撑的
- 性能执行
- 性能结果分析与调优
- 性能监控数据 ====分析 是否有问题
- 如果没有问题： 记录数据，写测试报告
- 如果有问题，就要进行性能分析
- 从一堆乱如麻的数据中，抽丝剥茧，找出有用信息（猜测、经验猜测）
- 调优，追求整体最优，而不是某一个最优(水桶效应)
- 性能监控数据 ====分析 是否有问题
- 性能问题跟踪性能报告提交
-
jmeter会自动生成一份HTML报告，有图形，但是这些图形，不能组合我们在写word测试报告，就要把html报告中的多个图形截图写在报告中。
-
-
脚本持续运行时间
-
我们在调试，运行的时候一般是设置为几十秒
-
真正做性能测试，想要得到性能指标，持续运行时间长度一般为几分钟~十几分钟
-
- 性能测试准备
-
哪些需要做性能测试
-
有监管要求的项目（ZF/国企项目）
-
涉及生命财产安全(安防/医疗……)
-
核心功能（使用人多，最挣钱的）
-
架构调整，极限审计（架构整体升级/jdk升级）
-
预计会流量激增的活动（双十一活动）
-
-
行业标准
- http\https协议族 接口
- 平均响应时间 <=1.5s && Error%<=0.1%
- 注意： 错误率，如果是偶尔的几次错误，错误率没有超过0.1%可以不用管，如果超过了，我们也是要分析原因的；如果是连续的，那么，要么是达到瓶颈，要么就是要性能分析找出问题。
- 如何判断有性能问题？
1、是否有连续报错-----有，且性能指标次数不满足要求，就要性能分析与调优
2、tps的趋势，有明显下降 -----此时，我们要看这个拐点的 性能指标是否满足要求，如果不满足，就要性能分析
3、平均响应时间是否超过1.5s ---此时，我们不能接受，我们期望它的性能能更好
性能测试思路
性能测试中，平均值的作用是十分有限的，平均值代表前后各有50%的量，对于一个敏感的性能指标，我们取平均值到底意味着什么？是让50%的用户对响应时间happy，但是50%的用户感知到响应延迟？还是说50%的时间系统能保证稳定，而50%的时间系统则是一个不可控状态？
平均响应时间这种指标，只有在你每次请求的响应时间都是几乎一样的前提下才会有一样。再来个例子
，人均财富这个概念有多沙雕相信大家也明白，19年有个很搞笑的新闻——腾讯员工平均月薪七万，明白平均值多不靠谱了吧😂。下图是现实世界中一个系统的响应时间柱状图，RT在前20%的请求数较少，但是因为耗时特别短（拉高了均值可能是命中缓存，也可能是请求的快速失败），而大多数RT是在均值之下，那才是系统的实际性能情况。
所以说，我们不应看最好的结果，相反地，应该控制最坏的结果，用户用得爽他不保证会传播好口碑，但是用户用到生气他保证变为键盘侠肆意大骂，这也是为什么平均值无法带来足够的参考，因为happy的结果蒙蔽了我们的双眼，平均值在压测中丢失太多信息量。
为什么响应时间（latency）要和吞吐量（TPS）挂钩
系统的性能如果只看吞吐量，不看响应时间是没有意义的。我的系统可以顶10万请求，但是响应时间已经到了5秒钟，这样的系统已经不可用了，这样的吞吐量也是没有意义的。
我们知道，当并发量（吞吐量）上涨的时候，系统会变得越来越不稳定，响应时间的波动也会越来越大，响应时间也会变得越来越慢，而吞吐率也越来越上不去（如下图所示），包括CPU的使用率情况也会如此。所以，当系统变得不稳定的时候，吞吐量已经没有意义了。吞吐量有意义的时候仅当系统稳定的时候。
所以，吞吐量的值必需有响应时间来卡。比如：99%的请求小于100ms的时候，系统可以承载的最大并发数是1000qps。这意味着，我们要不断的在不同的并发数上测试，以找到软件的最稳定时的最大吞吐量。
为什么响应时间吞吐量和成功率要挂钩
我们这应该不难理解了，如果请求不成功的话，都还做毛的性能测试。比如，我说我的系统并发可以达到10万，但是失败率是
40%，那么，这10万的并发完全就是一个笑话了。
性能测试的失败率的容忍应该是非常低的。对于一些关键系统，成功请求数必须在100%，一点都不能含糊。
总结一下，较为科学的评估方法应该将指标-成功率-流量三者挂钩在一起的：
xx%的响应在xx毫秒内返回，其中成功率为xx%。
根据这个方针，可以得到一些测试思路：
- 你得定义一个系统的响应时间latency，建议是TP99（99%的请求需要小于该时间），在响应时间的限制下，找到系统最高的吞吐量（这里不对吞吐量做严格定义，当成是QPS或TPS即可）
- 在这个吞吐量做Soak Test，比如：使用第一步测试得到的吞吐量连续7天的不间断的压测系统。然后收集CPU，内存，硬盘/网络IO，等指标，查看系统是否稳定，比如，CPU是平稳的，内存使用也是平稳的。那么，这个值就是系统的性能
- 在容忍一定的失败率和慢响应的情况下，找出系统最高能承受的吞吐量（95%成功率，前95%的请求响应时间为xx毫秒时的最大QPS）。或者对失败率0容忍的情况下找到系统的极限值。比如：在成功率100%的情况下（不考虑响应时间的长短），系统能坚持10分钟的吞吐量。
- 在上面的场景下还要考虑时间和资源，比如最高吞吐量持续10分钟和持续1小时是不一样的，不同的时间持续长度下，机器资源（cpu、内存、负载、句柄、线程数、IO、带宽）的占用是否合理
- 做Burst Test。用第一步得到的吞吐量执行5分钟，然后在第三步得到的极限值执行1分钟，再回到第一步的吞吐量执行5钟，再到第三步的权限值执行1分钟，如此往复个一段时间，比如2天。收集系统数据：CPU、内存、硬盘/网络IO等，观察他们的曲线，以及相应的响应时间，确保系统是稳定的。
- 低吞吐量和网络小包的测试。有时候，在低吞吐量的时候，可能会导致latency上升，比如TCP_NODELAY的参数没有开启会导致latency上升（详见TCP的那些事），而网络小包会导致带宽用不满也会导致性能上不去，所以，性能测试还需要根据实际情况有选择的测试一下这两个场景。
目标预估
压测开展前是需要有目标的，也就是有期望的性能情况，希望接口或系统能达到的性能预期，没有目的的压测是浪费人力，下面给出几种目标预估的方法
1.历史监控数据
已经上线并且有历史监控数据的接口，可以查看历史数据，找出峰值QPS和PCT99。 若接口A已经上线并且做了监控，在经过某次大活动或者上线时间足够长后，存量监控数据就可以使用了。
2.类比
新接口或者线上未监控的接口，不存在历史数据，但存在类似功能接口的历史监控数据，可以通过类比得出压测的目标。假设上一年淘宝双十一下订单接口QPS=x，RT（响应时间）=y，这一年天猫平台整起来了，双十一活动与上年淘宝双十一活动场景类似，也沿用QPS=x，RT=y的目标（例子不严谨，理解即可）。
3.估算
新接口或者线上未监控的接口，不存在历史数据，且不存在类似功能接口的数据可供参数考，此时需要估算峰值，常用方法有8|2原则 即：一天内80%的请求会在20%的时间内到达。
top QPS = (总PV * 0.8) / (60 * 60 * 24 * 0.2) PV(page view)
RT如无特殊要求，一般采用默认值(针对淘宝平台这类网站)：
- 单服务单表类，RT<100ms
- 较复杂接口，RT<300ms
- 大数据量或调用链较长的接口，RT<1s
-1 电商秒杀活动，预估同时有1000w人参与，简单起见假设总QPS是1000w。由于前端不同的秒杀倒计时形式使得请求有2s的打散，再加上nginx等webserver做了20%几率拒绝请求的策略，所以下单接口总QPS = 1000w / 2 * (1 - 0.2) = 400w/s，最终压测目标为400w/s的QPS。
-2 电商全天低价抢购活动，屠龙宝刀，点击就送，一刀99级，emmmmm跑题了。根据8|2原则，预估在午休（12-1）和晚上下班后（7-10）共4h是流量高峰，
估算接口峰值QPS = 活动全天接口PV / (4*3600s)。
4.其他
除了前面说到的情况，肯定还有一些我们无法下手的三无接口，无参考、无预估、无历史数据，这时候只能一点一点来，慢慢把压力提上去的同时收集数据，最终得出接口的最优处理能力。
(又得拿出这张图了)
918
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
