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

朱zhu · 2020年05月19日 · 最后由 DUxuebing 回复于 2020年05月22日 · 12 次阅读

最近公司要做服务端压力测试,我来负责;
产品:我要求系统必须满足 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 条回复 时间 点赞

前排坐好学习

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

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

朱zhu 回复

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

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

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

朱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 · 2020年05月20日 Author
吉吉里 回复

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

朱zhu #14 · 2020年05月20日 Author
zailushang 回复

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

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

朱zhu 回复

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

朱zhu #17 · 2020年05月20日 Author
zailushang 回复

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

朱zhu 回复

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

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

朱zhu 回复

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

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

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册