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

感谢。活动场景有些变化 人数变为 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，做起来就舒心多了

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

感谢赐教

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