一个查询接口，需求只说明了使用频率约为 50/s
期望得出其查询的性能瓶颈（响应时间和 TPS），但是在场景设计方面不太确定，特在此请教各位大大
铺底环境：表内数据 400w，此请求响应数据量 3w
我有考虑过 (成功率都是 100%)
1.30-100 以 10 个一组进行并发递增，查看其响应时间和 TPS 情况，得出 TPS 期望值为 25 并发-24，峰值/拐点为 35 并发-28，相应时间也是如此对应点（40 并发）
2.50 并发无限循环持续加压运行 10 分钟，目标 TPS 为 25，查看其相应时间的期望点
希望各位大佬帮忙看看场景是否合适及缺陷，还是否有其他的场景点及注意点，在加压和指标观察点处也有些不清晰
自顶！！！
请教各位大佬 TPS/响应时间在设计用例时的相互关系
TPS 期望值为 25 并发-24，峰值/拐点为 35 并发-28
这一段没太看懂。你需求里这个接口的响应时间要求是多少，好像没提到？
得出其查询的性能瓶颈（响应时间和 TPS）
针对这类需求，个人的一般玩法是：不断加压（比如 50 并发持续 3 分钟，然后 100 并发 3 分钟，直到达到典型业务场景的 5-10 倍），直到看到 TPS 恒定，响应时间随着加压而对应增加的现象。见到这个现象说明已经达到系统瓶颈了。至于多大算是极限，取决于可接受的响应时间有多大。
另外，也会测试下增加节点带来的性能提升情况，因为实际线上业务很可能突然压力会增大很多，这个时候直接加节点是最有效最快速的手段。需要看看加节点是否能提升性能，进而确定线上如果突然有活动，是否可以直接加节点解决。如果加节点无法提升性能的，需要想办法优化或者找到其他的能应对压力增大的预案。
单接口的话就没有太多场景可以设置了吧，主要考虑接口的查询逻辑和要关注的性能点，服务器压力、数据库压力等等，然后接口是否有缓存，存储层查询是否有缓存等等，中间件层等等，接口参数化等等（例如单一接口是动态参数，考虑业务场景下的不同参数）等等等等
你这个 50/s 是每秒请求呀，不是服务处理能力。吞吐量控制器控制的是你的每秒的总响应数。
所以这里你有两个场景要考虑【50/s 是指的一个人 1s 内查询了 50 次还是很多人在 1s 内总共查询了 50 次请求】
如果是第一种，那这个 50 就是总 tps 呀，处理能力已经被你圈死了
如果是第二种，那你就要先计算平均并发数，然后再去测你的性能瓶颈
还有不要同时艾特我跟几位社区大佬，我不配。。。
性能测试一般来说分为多个阶段、跑基线、阶梯加压到预期目标、跑基线、跑浸泡（不一定算）等等，看你针对的场景。一般我们认为跑性能测试的目的是为了找系统资源的拐点，建议可以结合性能监控工具采集并绘制相关折线图，便于分析定位瓶颈。希望对您有帮助
多谢各位大佬的回复，不胜感激