时间什么时候正式公布，外地小伙伴准备抢个票

北京现在要求隔离，到时候还是这样会议会延期吗

要了解一下直播的原理吧，看前端如何实现请求，我们做的就是模拟前端请求。测试过程和其他测试应该是一样的。

你的线程组是依次运行还是一起运行的？有点像运行到指定接口或者缓存失效重新拉取的感觉。

薪资和能力匹配，欢迎尝试。

QAQ 新招的性能测试同学回老家结婚了，重新招聘一位。

楼主厉害了。
这边列出的问题基本命中基本的性能测试基础题，面试官还会希望候选人结合项目聊一下，切中项目中的环节再进行来回问答。

喵喵喵？你想应聘我 leader？

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

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。

仅供参考。