- 性能测试流程
- 性能测试准备
- 需求分析:鉴别需求的目的,目标
- 业务要熟悉:功能,架构,环境
- 测试计划:什么人,在什么时间,做什么事情,工作量评估
- 性能测试的时间 ~= (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.其他
除了前面说到的情况,肯定还有一些我们无法下手的三无接口,无参考、无预估、无历史数据,这时候只能一点一点来,慢慢把压力提上去的同时收集数据,最终得出接口的最优处理能力。
(又得拿出这张图了)