性能常识 [请教] 关于抢红包活动的性能测试需求量化

kasijia · December 09, 2019 · Last by kasijia replied at December 10, 2019 · 1353 hits

活动场景如下:
预估参与人数:20万
活动策略:提前通知所有用户活动开始时间及结束时间
活动持续时间:5分钟
每个用户单独完成抢红包流程总共需要调用10个接口

请教这样的活动大家会如何设计性能测试策略,以及期望TPS、Jmeter施压的并发数如何评估?

下面是我根据自己的理解结合二八原则计算的预期TPS值:

(更正后)TPS=(200000*80%)/(5*60*20%) => 约等于2666

测试策略:
短时间高并发:保持高并发情况下持续运行1分钟,平均TPS达到2666并且平均响应时间小于5s即通过。
长时间低并发:保持相对较低并发情况下持续运行5分钟+预估延长时间(1~2分钟左右),系统稳定运行且平均响应时间小于2s即通过。

共收到 8 条回复 时间 点赞

针对一般的业务可以这样算:根据2/8原则,80%的请求会发生在20%的时间内,10W * 80% / (168h * 20%) = 2380次/h,换算下来1s不到一次;但是由于抢红包的特殊性,可能90%以上的人都会在前几个小时内操作,算下来大概也就10TPS。

arrow 回复

感谢。活动场景有些变化😀 人数变为20万,时间持续5分钟。
我自己的计算公式是参考另一篇文章的,计算公式中的分子乘了下完成事务所需的接口数,但我觉得你的才是正确的,假如乘以接口数我的理解是计算出来的是QPS而不是TPS。
应该是:TPS=(200000*80%)/(5*60*20%) = 2666
不知道我理解的有没有问题

首先有几个问题,有我个人的猜测成分在内,如有猜测错误,也请见谅。

  1. 20W是总共参与的人数吗?还是抢红包人数?(和抢红包业务通知给多少用户是有一定比例关系的)

  2. 抢红包的规则是怎么样的?
    是有红包个数限制还是5分钟抢都有?
    这两者,前者类似QQ/wechat抢红包,后者类似支付宝时间段兑奖
    如果是前者,用户的并发量会更高一点,用二八法则是否合理有待考证。
    并发量会在抢完红包之后出现一个骤降的情况,抢不到和抢得到红包的逻辑应该也会不一样。

如果是后者,用二八原则计算相对合理,但是兑奖并发量可能也不会那么高?

  1. 「每个用户单独完成抢红包流程总共需要调用10个接口」,是每次抢都会调用10个接口还是怎么?10个接口是否有可以提前做的? 如果第一次没抢到第二次抢实际调用的是哪些接口? 重试调用的接口和用户的人数可能不是1:1的关系,响应时间超过用户预期 + 抢红包的心理 有可能会出现用户多次重试。

总之我建议从真实抢红包业务去解读服务需要达到的处理能力。

  1. 根据上述提问的内容了解更多的抢红包的信息,不要匆忙计算TPS,我们从业务方角度得到的不一定是准确的TPS,做好预判工作;
  2. 性能测试的策略中因为活动本身只有5分钟,我认为没有必要分成两种测试,就测试高并发5分钟,查看是否可以达到预期目标。
    “没必要”指的是在这种业务中性价比比较低,如有余力,也可以做,活动一共就5分钟。

  3. 做好开始前后的工作和合理的提示。
    1)开始前不允许用户点击按钮的话,刷新抢红包页面的性能需要保证。
    2)红包已经没有了之后,页面需要禁止点击按钮,减少服务的压力。
    3)控制连接数,不是所有用户都需可以建连成功,提示用户重试。
    4)减少抢红包接口被暴力请求的可能。

  4. JMeter线程数的设置
    1)如果从业务方拿到的是TPS。
    JMeter 线程可以阶梯式往上涨,,1,25,50,100,200,400翻倍涨,找到满足预期TPS对应的线程数,或者TPS不再增长、响应时间突然飙升的值。
    这边的线程数不是用户数。

2)如果从业务方拿到的是用户数。
JMeter的线程数即是用户数,此刻需要考虑的是各个接口之间的思考时间。
思考时间是用户实际的停顿时间,会影响到实际的TPS。

仅供参考。

需求不能量化,能量化的是指标
你可以先把需求转化为(评测的)指标,然后对指标进性量化
你已经有一些比较具体的需求(20万、持续时间5min),涉及接口数n
从需求来讲,就是:20万个用户,在持续5分钟内,连续调用这n个接口的整个过程里面:流畅、稳定、成功率高
所以,这里的评测指标除了你已经提到的:TPS
应该至少还包括:各接口的平均响应时间、响应时间方差、(n个接口作为一个事务的)事务通过率

平均TPS达到2666并且平均响应时间小于5s

看起来你的并发数需要13330起步啊,这个需要多少分布式负载客户端和带宽呀,想想我都头大
如果响应时间能优化到0.5s,做起来就舒心多了

Garfield 回复

感谢回复这么细致的分析。确实你提到的许多细节先前都没有考虑到,对业务准确的解读是为了得到更准确的指标值,单单用公式硬套出来的指标与实际情况肯定会有比较大的偏差,受教了😀

BNN 回复

😀 感谢赐教😀

槽神 回复

确实,假如按5s作为标准的话确实很不合理,受教了。刚接触性能测试不久,还处于消化基础概念的阶段😂

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