51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 1081|回复: 0

服务端压力测试怎么做,你知道么?

[复制链接]
  • TA的每日心情
    无聊
    6 小时前
  • 签到天数: 919 天

    连续签到: 1 天

    [LV.10]测试总司令

    发表于 2022-5-7 11:19:03 | 显示全部楼层 |阅读模式
    可能很多QA、RD同学跟我都一样,对服务端压测一直没有系统的认知,印象停留在使用压测工具如Jmeter对单接口发压,调整线程数和循环数来制造不同压力,最后计算一下TPS和成功率等就完事了?网上虽然有不少压测相关的文章,但多数是压测工具的入门级使用,有的是压测流程和指标的简单解释,或者就是几个大厂牛逼的全链路压测能力和压测平台的介绍。这些文章要不缺少系统性阐述,要不过于抽象不好理解,对没怎么接触过压测的同学不太友好。
      本文尝试在QA角度梳理一次完整的压测过程,尝试总结更为普适的压测思路,给大家提供更有意义的参考。

      压测背景
      测试分很多种,网上很多文章[1]会玩弄概念,搬出来3个名词:压力测试(Stress Testing)、性能测试(Performance Testing)、负载测试(Load Testing)。一般情况下并不需要做这么细粒度的概念区分,这3个概念我觉得是没办法完整区分各自边界的,至少在程序逻辑上难以做得到,更多差异只是来自于不同的压测策略,所以尽管忽略这几个概念的区别,都叫它压测或者性能测试即可。

      为什么需要压测
      拿技术人熟知的阿里举例,应该是国内做压测最好的一个大厂。外界熟知的阿里2012双11活动,2012年11月11日零点,阿里各种系统报错、立刻下单报错、购物车支付报错、支付系统报错、购物车的东西丢失,系统显示交易成功率不到50%,产生了大量超卖,给阿里带来很大的损失。那一年的双11后,库存、商品、退款和相应数据库的同学,为了处理超卖导致的问题,没日没夜加了两周的班,同时给了用户不少糟糕购物体验。
      为什么出现这么严重的问题?因为对整个全交易链路上的各个子系统的承受能力不清楚,并且错误预估了可能会达到的流量,也没有完善的预案,兵败如山倒。
      2013年阿里首次提出了全链路压测方案:一方面可让链路的各个系统知道自己的承压极限;另一方面可让各个系统有个明确的优化目标,了解到整个链路的瓶颈并评估资源情况。

      单系统压测与全链路压测
      为什么只做单系统压测还不够呢?
      在活动开始的瞬间,各系统都面临自身服务的巨大的压力,而系统之间是有互相依赖关系的,单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障,故障会在链路流转过程中层层累加,会造成无法评估的影响。
      所以最可靠的方式是完全模拟真实场景来压测,通过线上全链路压测提前发现问题。

      压测流程
      完整的压测流程一般包含下面几个步骤:
      压测目标的制定
      压测链路的梳理
      压测环境的准备
      压测数据的构造
      发压测试
      瓶颈定位及容量微调
      压测总结

    压测目标
      压测作用
      新服务,无预估目标,需要通过压测得到服务基准数据或找到系统瓶颈进行优化
      有明确的压测目标,需要通过压测确定服务的各项指标是否达标
      常态化压测,为后期性能优化指导方向或提供参考依据

      压测指标
      列举一些常用指标,并不一定都需要关注,根据业务考虑指标的细化粒度。
      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%的时间系统则是一个不可控状态?
      平均响应时间这种指标,只有在你每次请求的响应时间都是几乎一样的前提下才会有一样。再来个例子,人均财富这个概念有多沙雕相信大家也明白,19年有个很搞笑的新闻——腾讯员工平均月薪七万,明白平均值多不靠谱了吧。下图是现实世界中一个系统的响应时间柱状图,RT在前20%的请求数较少,但是因为耗时特别短(拉高了均值可能是命中缓存,也可能是请求的快速失败),而大多数RT是在均值之下,那才是系统的实际性能情况。

     所以说,我们不应看最好的结果,相反地,应该控制最坏的结果,用户用得爽他不保证会传播好口碑,但是用户用到生气他保证变为键盘侠肆意大骂,这也是为什么平均值无法带来足够的参考,因为happy的结果蒙蔽了我们的双眼,平均值在压测中丢失太多信息量。
      总结一下,较为科学的评估方法应该将指标-成功率-流量三者挂钩在一起的:
      xx%的响应在xx毫秒内返回,其中成功率为xx%。
      根据这个方针,可以得到一些测试思路:
      在响应时间的限制下,系统最高的吞吐量(这里不对吞吐量做严格定义,当成是QPS或TPS即可)
      在成功率100%的前提下,不考虑响应时间长短,系统能承受的吞吐量
      容忍一定的失败率和慢响应,系统最高能承受的吞吐量(95%成功率,前95%的请求响应时间为xx毫秒时的最大QPS)
      在上面的场景下还要考虑时间和资源,比如最高吞吐量持续10分钟和持续1小时是不一样的,不同的时间持续长度下,机器资源(cpu、内存、负载、句柄、线程数、IO、带宽)的占用是否合理。

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

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

      类比
      新接口或者线上未监控的接口,不存在历史数据,但存在类似功能接口的历史监控数据,可以通过类比得出压测的目标。?? 假设上一年淘宝双十一下订单接口QPS=x,RT=y,这一年天猫平台整起来了,双十一活动与上年淘宝双十一活动场景类似,也沿用QPS=x,RT=y的目标(例子不严谨,理解即可)。

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

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





    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-29 16:15 , Processed in 0.077062 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表