最近在对代码进行压力测试,这里整理一下压测中的指标和方法。

1 压力测试中的指标

1.1 TPS

TPS 即Transactions Per Second的缩写,每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程**(完整处理,即客户端发起请求到得到响应)**。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数,最终利用这些信息作出的评估分。一个事务可能对应多个请求,可以参考下数据库的事务操作。

1.2 QPS

QPS 即Queries Per Second的缩写,每秒能处理查询数目(完整处理,即客户端发起请求到得到响应)。是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
我们从它的英文全名可以得出它是查询意思,原来在因特网上,作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec,即每秒的响应请求数。 虽然名义上是查询的意思,但实际上,现在习惯于对单一接口服务的处理能力用QPS进行表述(即使它并不是查询操作)。

1.3 平均处理时间(RT)

RT:响应时间,处理一次请求所需要的平均处理时间。
我们一般还会关注90%请求的的平均处理时间,因为可能因网络情况出现极端情况。

1.4 并发用户数(并发量)

每秒对待测试接口发起请求的用户数量。

1.5 换算关系

QPS = 并发数/平均响应时间
并发量 = QPS * 平均响应时间

比如3000个用户(并发量)同时访问待测试接口,在用户端统计,3000个用户平均得到响应的时间为1188.538ms。所以QPS=3000/1.188538s= 2524.11 q/s。
我们就可以这样描述本次测试,在3000个并发量的情况下,QPS为2524.11,平均响应事件为1188.538ms

1.5 TPS和QPS的区别

这个问题开始,我认为这两者应该是同一个东西,但在知乎上看到他们的英文名,现在我认为:
QPS 每秒能处理查询数目,但现在一般也用于单服务接口每秒能处理请求数。
TPS 每秒处理的事务数目,如果完成该事务仅为单个服务接口,我们也可以认为它就是QPS。

PS:还有一个RPS的的概念 request per second 。每秒请求数,在一定条件下和QPS 和TPS类似。

2 压力测试方法

我们可以使用压测工具模拟多用户对系统进行压力测试。后面会有压测工具的介绍

而测试的方式是,以一定请求总量,保持不变,逐步增加并发量,观察QPS的变化及平均响应时间的变化。
比如10000的总请求数,然后测试100的并发量情况下的QPS值,然后200, 300, 400, 500等。

一个系统吞吐量通常由TPS、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达 到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。这里给出一份使用ab工具的压测图。
在这里插入图片描述
从图中可以看出2000的并发量时,QPS已经达到2500左右,后续加大并发数仍维持在2500,说明该接口在该配置下,QPS为2500,即每秒该系统的能力只能处理2500个请求左右,后面加大的并发量,只会导致平均响应时间的增加。(PS:因为每秒只能处理2500个请求,而一次性有7000的并发,自然会造成请求堆积,导致平均响应时间会变长)我们看到超过14000之后连QPS也开始急剧下降,说明系统超负荷工作,导致性能开始急剧下降。而一般情况下,我们认为平均响应时间达到一定值,就已经不可以接受了。

3 相关文档

估计物联网设备并发量整理的blog:
https://blog.csdn.net/m0_37263637/article/details/88649056
压力测试工具ab工具:
https://blog.csdn.net/m0_37263637/article/details/78558890
Node express框架压测结果:
https://blog.csdn.net/m0_37263637/article/details/88749198

Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐