性能测试策略总结

做性能测试需要一套标准化流程及测试策略。在做负载测试的时候,传统方式一般都是按照梯度施压的方式去加用户数,避免在没有预估的情况下,一次加几万个用户,导致交易失败率非常高,响应时间非常长,已经超过了使用者忍受范围内;较为适合互联网分布式架构的方式,是用TPS模式(吞吐量模式)+设置起始和目标最大量级,然后根据系统表现灵活的手工实时调速,效率更高,服务端吞吐能力的衡量一步到位。

压测TPS相关概念:

  • HPS(Hits Per Second) :每秒点击次数,单位是次/秒。
  • TPS(Transaction per Second):系统每秒处理交易数,单位是笔/秒。
  • QPS(Query per Second):系统每秒处理查询次数,单位是次/秒。对于互联网业务中,如果某些业务有且仅有一个请求连接,那么TPS=QPS=HPS,一般情况下用TPS来衡量整个业务流程,用QPS来衡量接口查询次数,用HPS来表示对服务器点击请求
  • RPS 即每秒请求数(Request Per Second),通常用来描述施压引擎实际发出的压力大小。PS:并发数过低时可能达不到预期的 RPS,并发数过高时可能压力过大压垮服务器
  • 并发用户数:简称VU ,指的是现实系统中操作业务的用户,在性能测试工具中,一般称为虚拟用户数(Virutal User),注意并发用户数跟注册用户数、在线用户数有很大差别的,并发用户数一定会对服务器产生压力的,而在线用户数只是 ”挂” 在系统上,对服务器不产生压力,注册用户数一般指的是数据库中存在的用户数。
  • 处理能力:简称TPS, 每秒事务数, 是衡量系统性能的一个非常重要的指标。
  • 响应时间:简称RT,指的是业务从客户端发起到客户端接受的时间。

性能测试场景设置思路

无论并发模式还是TPS模式,场景就是一个压测模型,压测模型中有串行的事务(如添加购物车+购物车下单+付款)也有并行的接口(在不同串联链路中的压测API),最终组成一个复杂或者简单的场景。然后根据新业务上线的目标、或者日常峰值的等比例目标、或者重大业务活动的预估支撑能力去设置每个API的目标能力(TPS是一步到位的按照吞吐能力设置的,推荐TPS模式,比如前面提到的添加购物车+购物车下单+付款这种流程就是一个漏斗模型,TPS设置为逐渐变小的模型即可),当然也可以在初期的测试中更谨慎一点,将目标量级设置得整体低一点,当最终能力达到之后建议可以调整原定目标量级到120%或者150%,验证限流准入/高可用基础设施的抗压能力。目标量级即当前压测场景中这个压测API的施压上限。而起步量级可以从5%或者10%开始,过程中视业务指标数据和被压测端的整体负载临时调整

##基本概念##

什么是并发用户、TPS 和它们之间的关系。

  • 并发用户:指的是现实系统中同时操作业务的用户,在性能测试工具中一般称为虚拟用户(Virutal User)。一般是站在客户侧评估的角度,但是不便于服务端的一些容量评估和高可用评估。

    并发用户跟注册用户、在线用户有很大差别。并发用户一定会对服务器产生压力,在线用户数只是 “挂” 在系统上,对服务器不产生压力,而注册用户一般指的是数据库中存在的用户。

  • TPS:Transaction Per Second, 每秒事务数, 是衡量系统性能的一个重要指标。在 PTS 中,为了直接评估TPS,也可以采用RPS(Request Per Second,每秒请求数)设置压测流量的大小。RPS模式更适合容量规划和作为限流管控的参考依据。

例子:假如 1 个虚拟用户在 1 秒内完成 1 笔事务,那么 TPS 就是 1。要想达到 1000 TPS 至少需要1000 个用户;如果某笔业务响应时间是 1 毫秒,那么 1 个用户在 1 秒内能完成 1000 笔事务,TPS 就是 1000。

因此 1 个用户可以产生 1000 TPS,1000 个用户也可以产生 1000 TPS,主要看响应时间的快慢。

##设置目标并发(或RPS)##

对于并发用户数的评估:

  • 可以选取线上系统在高峰时刻一定周期内使用系统的人数,这些人数可以认为是在线用户数,并发用户数取其 10% 就可以了。例如在 1 小时内使用系统的用户数为 10000,一般建议取 10% 左右作为并发用户数。

  • 未上线系统或新上线系统:因没有历史数据可供参考,故只能通过业务发展趋势来预判各项指标。

对于 TPS(RPS)的评估:

  • 线上系统:通过线上系统在高峰时刻 10 分钟内完成的业务量,计算出在单位时间内的处理笔数,即 TPS(RPS) = 业务笔数/单位时间(10*60,以秒为单位)。

  • 未上线系统或新上线系统:因没有历史数据可供参考,故只能通过业务发展趋势来预判各项指标。

简要总结:

  • 系统的性能由TPS决定,跟并发用户数没有多大关系
  • 系统的最大TPS是一定的(在一个范围内),但并发用户数不一定,可以调整。
  • 建议性能测试的时候,不要设置过长的思考时间,以最坏的情况下对服务器施压。
  • 一般情况下,大型系统(业务量大、机器多)做压力测试,10000~50000个用户并发,中小型系统做压力测试,5000个用户并发比较常见。


    !!!针对服务器端的性能,以TPS为主来衡量系统的性能,并发用户数为辅来衡量系统的性能,如果必须要用并发用户数来衡量的话,需要一个前提,那就是交易在多长时间内完成,因为在系统负载不高的情况下,将思考时间(思考时间的值等于交易响应时间)加到串联链路(场景)中,并发用户数基本可以增加一倍,因此用并发用户数来衡量系统的性能没太大的意义。同样的,如果系统间的吞吐能力差别很大,那么同样的并发下TPS差距也会很大。
  • 3
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 6
    评论
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值