如何评估服务端压测指标

压测流程

完整的压测流程一般包含下面几个步骤:

1、压测目标的制定
2、压测链路的梳理
3、压测环境的准备
4、压测数据的构造
5、发压测试
6、瓶颈定位及容量微调
7、压测总结和报告

压测指标

列举一些常用指标,并不一定都需要关注,根据业务考虑指标的细化粒度。

  • QPS:Query Per Second,每秒处理的请求个数 TPS:Transactions Per Second,每秒处理的事务数,TPS <= QPS RT:Response Time,响应时间,等价于Latency
  • RT分平均延时,Pct延时(Percentile分位数)。平均值不能反映服务真实响应延时,实际压测中一般参考Pct90,Pct99等指标
  • CPU使用率:出于节点宕机后负载均衡的考虑,一般 CPU使用率 < 75% 比较合适
  • 内存使用率:内存占用情况,一般观察内存是否有尖刺或泄露
  • Load指标:CPU的负载,不是指CPU的使用率,而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,表示CPU的负载情况,一般情况下Load < CPU的核数*2
  • 缓存命中率:多少流量能命中缓存层(redis、memcached等)
  • 数据库耗时:数据库就是业务的生命,很多时候业务崩掉是因为数据库挂了
  • 网络带宽:带宽是否瓶颈
  • 接口响应错误率 or 错误日志量

这里要说明一下QPS和TPS的区别:

  • QPS一般是指一台服务器每秒能够响应的查询次数,或者抽象理解成每秒能应对多少网络流量
  • TPS是指一个完整事务,一个事务可能包含一系列的请求过程。举个例子,访问一个网页,这是一个TPS,但是访问一个网页可能会对多个服务器发起多次请求,包括文本、js、图片等,这些请求会当做多次QPS计算在内,因为它们都是流量性能测试中,平均值的作用是十分有限的,平均值代表前后各有50%的量,对于一个敏感的性能指标,我们取平均值到底意味着什么?是让50%的用户对响应时间happy,但是50%的用户感知到响应延迟?还是说50%的时间系统能保证稳定,而50%的时间系统则是一个不可控状态?

总结一下,较为科学的评估方法应该将指标-成功率-流量三者挂钩在一起的,比如:99%的响应在500毫秒内返回,其中成功率为99.99%。

根据这个方针,可以得到一些测试思路:
1、在响应时间的限制下,系统最高的吞吐量(这里不对吞吐量做严格定义,当成是QPS或TPS即可)
2、在成功率100%的前提下,不考虑响应时间长短,系统能承受的吞吐量
3、容忍一定的失败率和慢响应,系统最高能承受的吞吐量(95%成功率,前95%的请求响应时间为xx毫秒时的最大QPS)
4、在上面的场景下还要考虑时间和资源,比如最高吞吐量持续10分钟和持续1小时是不一样的,不同的时间持续长度下,机器资源(cpu、内存、负载、句柄、线程数、IO、带宽)的占用是否合理

目标预估

压测开展前是需要有目标的,也就是有期望的性能情况,希望接口或系统能达到的性能预期,没有目的的压测是浪费人力,下面给出几种目标预估的方法。

历史监控数据

已经上线并且有历史监控数据的接口,可以查看历史数据,找出峰值QPS和PCT99。若接口A已经上线并且做了监控,在经过某次大活动或者上线时间足够长后,存量监控数据就可以使用了。

类比

新接口或者线上未监控的接口,不存在历史数据,但存在类似功能接口的历史监控数据,可以通过类比得出压测的目标。

估算

新接口或者线上未监控的接口,不存在历史数据,且不存在类似功能接口的数据可供参数考,此时需要估算峰值,常用方法有8/2原则——一天内80%的请求会在20%的时间内到达。
top QPS = (总PV * 0.8) / (60 * 60 * 24 * 0.2)
RT如无特殊要求,一般采用默认值:
单服务单表类,RT<100ms
较复杂接口,RT<300ms
大数据量或调用链较长的接口,RT<1s

其他

除了前面说到的情况,肯定还有一些我们无法下手的三无接口,无参考、无预估、无历史数据,这时候只能一点一点来,慢慢把压力提上去的同时收集数据,最终得出接口的最优处理能力。

你可能感兴趣的:(压测,压力测试,性能优化)