性能测试策略总结

快来打我* 2022-10-02 11:52 233阅读 0赞

### **做性能测试需要一套标准化流程及测试策略。在做负载测试的时候，传统方式一般都是按照梯度施压的方式去加用户数，避免在没有预估的情况下，一次加几万个用户，导致交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内；较为适合互联网分布式架构的方式，是用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差距也会很大。