性能测试工具 对于性能测试的一些想法,欢迎交流

朱zhu · May 19, 2020 · Last by DUxuebing replied at May 22, 2020 · 2161 hits

最近公司要做服务端压力测试,我来负责;
产品:我要求系统必须满足300并发的要求,系统用起来要流畅;
产品给出的指标就是上面两个:1.300并发;2. 流畅;OK,那就开始做吧;如果放在以前刚刚开始接触压测的时候,我肯定是写好脚本,直接上300个并发,在一些节点加思考时间,模拟用户行为来压测就行;但是这样是没法准确来模拟300个真正用户的操作场景的,可以说在脚本方面下功夫,无论如何也没法准确的模拟一定数量的用户对系统的操作的;
这个时候我们能不能通过抓取后台的服务日志,看一下每个服务在一段时间内,真正承受的压力是多少呢?我们可以看QPS,比如一天内最大的值是100QPS,这个时候我们就知道服务最大接到 的请求压力是100QPS,这个时候,我们就可以通过加大并发量,让服务承受的压力一直阶梯增加到50QPS 80QPS 100QPS 120QPS, 不用管jmeter加的并发量是多大,只调整jmeter的并发量,看服务端承受的QPS能否达到最大值就可以了!也不用再想法模拟飘忽不定的用户真实操作了;当jmeter设置到一定并发量,后台服务承受的压力是100qps了,这个时候系统还没有问题的话就满足产品的要求了;我们还可以接着加大并发量,直到压出系统的瓶颈;
这个过程的一切,我们只看后台服务的qps,并发量只是我们达到服务承受压力的一个手段而已;
这是个人的一些思考,欢迎性能大咖能提出质疑或者性能测试的方法,真诚跟大家交流请教,谢谢!
最后@一下大神@ZeeBJ,还请指正,感谢!

最佳回复

每个服务端承受了多少,不是根据你们的业务模型去确定的吗?

吉吉里 回复

赞同,某些系统没用并发数的概念,或者说并发数并不指代实际存在的用户,这种时候只看TPS是可以的,此时并发数只是增大压力的作用,但是针对某些业务系统而言,并发数是有实际意义的,指代的就是实际存在的用户,这种时候并发数就是有意义的,此时并发数是需要作为一个测试点的。比如某业务系统处理能力要求300TPS,300TPS假如可以用50并发测到,那么用100并发也绝对可测到(加间隔时间就可以),那么只考虑TPS,测试并发数为50,满足300TPS指标,测试通过,但是未验证并发数这个测试点,那么有可能你的系统在100并发出现问题,比如无法登陆,或者登陆时间过长等。

共收到 21 条回复 时间 点赞

前排坐好学习

每个服务端承受了多少,不是根据你们的业务模型去确定的吗?

朱zhu #3 · May 19, 2020 作者

我说的这个是在系统已经在是使用的情况下,有历史数据可以参考;即我们知道这个服务历史最高qps是多大,然后参考这个qps为基准来压测看是否满足这个最大的qps; 如果说是一个新系统上线的话,qps这块还没有一个历史最高参考值;你说的服务端承受了多少是指qps吗?还是用户在线数呢?

朱zhu 回复

模型就是根据你线上的业务去确定啊,然后算出每个服务的比例,继续加压也要根据比例去同步提升

朱zhu #5 · May 19, 2020 作者

但是你的并发量怎么确定呢?其实多少用户在线上使用和设置同样数量的并发量,对系统产生的压力是完全不同的;及时加上思考时间,集合点等尽量模拟用户行为,但是还是是不一样的

流畅?这个定义的太飘忽不定了。
当然还是看你们的产品吧,压测压了就压了,顺便也压下极限,卡不卡无所谓了,别完全压死无法自动恢复了那问题就大了。

我不明白你们为什么做业务系统的性能测试总提qps呀、rps呀之类的
一个用户操作,对应后端很可能就是一个API,一个API九成九的概率就是用一个事务来管理,一个事务里面包含多次依赖(其他服务)调用或者数据库读写,用户所关注的不就是这个完整的事务的响应吗,transaction per second这个指标到底哪里不好以致于大家都喜欢拿qps来衡量性能呢,你们是在做数据库中间件或者消息中间件的性能基准测试吗?

朱zhu 回复

并发量线上没数据?

抛砖引玉:
1、大部分情况,服务端容量就是看QPS,或则说(QPS,Latency,Error_Rate,CPU,Memory)这几个组合。单纯谈一个或几个指标是没有意义的,比如QPS很高,latency很大,或者错误率很高,这都是无效的
2、大部分情况下,服务端容量就是看QPS,并发数只是我们达到这个QPS的手段---这个是OK的
3、为什么说大部分情况下呢,因为对于某些场景下,并发数有特殊的含义。比如说websocket协议,比如游戏基于socket长链接这种情况下,系统看的是新建连接数,和连接保持数,这个是QPS解决不了的。
4、就楼主这个情况,300并发 != 300QPS。 产品告诉你300并发,我理解是最大同时支持300个用户并发操作,需要根据用户行为模型来预估最高QPS。这种情况下,可以看看线上高峰期时并发数是多少,然后对应的各个接口的QPS是多少,然后计算出300并发下,各个接口的QPS是多少,然后需要按照这个数据来进行压测。

三百人并发是什么意思呢? 三百人同时在线但是在做不同的事情,还是有一千人在线但是其中三百人同时在做同一件事情?

吉吉里 回复

赞同,某些系统没用并发数的概念,或者说并发数并不指代实际存在的用户,这种时候只看TPS是可以的,此时并发数只是增大压力的作用,但是针对某些业务系统而言,并发数是有实际意义的,指代的就是实际存在的用户,这种时候并发数就是有意义的,此时并发数是需要作为一个测试点的。比如某业务系统处理能力要求300TPS,300TPS假如可以用50并发测到,那么用100并发也绝对可测到(加间隔时间就可以),那么只考虑TPS,测试并发数为50,满足300TPS指标,测试通过,但是未验证并发数这个测试点,那么有可能你的系统在100并发出现问题,比如无法登陆,或者登陆时间过长等。

从产品模型和用户模型评估很难,需要很多维度,反而直接看线上历史峰值QPS是最准确的,然后通过接口或事务比例来构成业务场景即可。性能测试做到线上峰值的3倍,上线之后理论上是绰绰有余的。但是要考虑稳定性,因为很多问题是长时间压力才能暴漏的。

朱zhu #13 · May 20, 2020 作者
吉吉里 回复

这种情况下,可以看看线上高峰期时并发数是多少,然后对应的各个接口的QPS是多少—— 请教一下,这里所说的各个接口的QPS,是指接口每秒接收到的请求,还是每秒接到并处理完成的请求呢?

朱zhu #14 · May 20, 2020 作者
zailushang 回复

历史峰值QPS——您好,请问一下线上看历史峰值的QPS,一般我们在后台能看到的应该是每个接口每秒中接收到的请求吧,即QPS, 但是看好多文章说QPS又是指每秒中处理的请求数?所以是指哪个呢

弱弱的问一下,这个性能指标是怎么得到啊,比如这个要求的并发数

朱zhu 回复

要找哪些接口:定位到最前面的接口就行,即用户可以直接访问到的接口。
需要找什么数据:QPS( quests per second),后台统计的是,每个接口每秒接受的请求(这就是该接口的QPS),就是性能测试需要的数据。
怎么模拟场景:按照线上统计的接口比例,进行模式

朱zhu #17 · May 20, 2020 作者
zailushang 回复

谢谢指教啊,这样的话QPS其实要分为两个概念了吗?后端接口讲QPS,就是指每秒接收到的请求数;如果看接口每秒钟能处理多少个请求,可以跟据Jmeter工具,比如300并发/平均响应时间= QPS(接口处理能力)? QPS可以有不同的理解

朱zhu 回复

别管并发用户了,以QPS为准吧。老板要是问性能怎么样,他如果不懂性能,有多少QPS,就说可支持多少并发用户吧

性能测试分两种,容量测试和压力测试。(当然高楼是说性能测试其实就一种,不用分那么多,我这么说是便于理解)
你的问题,看起来你是把这两者混在一起了。细看你的要求更接近压力测试。
我遇到的90%吧,Jmeter的的范畴,剩下的,最应该用流量回放的方式搞,但是还是使用了Jmeter搞定。

朱zhu 回复

可以理解为接收的QPS吧,接收的QPS=处理完的QPS+错误QPS

楼上的各位都好厉害呀~ 能在testhome多发写这方面的帖子吗?
在testhome上其他热帖,很少讨论测试技能这块的,,,,, 看到标题都不想点进去。。。。。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up