两个数据都很重要。

TPS 是最直观的表明服务性能能力的一个指标，但是同样一个服务，在 1000 并发下和 2000 并发下的性能表现可能会差距很大。 1000 并发和 2000 并发对于服务来说，表示不同的连接压力。

举个例子：当服务最大处理能力为 1000TPS 时，当 1000 个并发压测时，平均响应时间为 1 秒。
但是当 2000 个并发压测时，因服务处理能力有限，平均响应时间可能会增加到 1.5 秒。

这个时候，当并发继续增加的时候，服务很可能出现性能拐点（QPS 大幅下降，响应时间大幅增加）。

所以，在日常压测中，开发同学还需要考虑，当大量并发链接请求来临时：
（1）是否会出现性能拐点
（2）到达性能拐点之前，是否需要增加降级方案
（3）对于易引发性能问题的并发数，是否要增加细粒度报警
等等
以及：
（1）在目前的基础上，是否可通过调整配置，来提高服务的 TPS 能力和应对并发的能力

监控和预警方便多聊聊吗？ 我们这边也是支付如果做正式环境拨测，比较费劲。

所以更多的是监控自身服务的拨测，期望隔离开第三方支付服务

我们这边全是 go，有类似 sandbox 这类的中间代理吗？

求指导，线上怎么 mock？

嗯嗯，是的，横捷，请教一下，你们之前的预警或监测机制大概是什么样的啊？

容量测试可以

嗯嗯，白名单专注于检测自家系统的质量。

关于第三方服务的监测：
（1）通过 UI 自动化（真实支付用例）监测
（2）第三方支付提供测试账号，用于接口拨测；

我理解的白名单，对于测试账号默认不调用支付系统，只覆盖基本逻辑。

嗯嗯，这样可以。 是不是也可以加白名单，对于测试账号默认不调用支付系统，只覆盖基本逻辑。

请教各位有过在线支付接口测试经验的朋友，帮忙回答一下，多谢

请教一下恒捷，如果对在线支付做正式环境的拨测的话，是不是只有白名单一条路走了

本文 转自九边的微信公众号，麻烦@Onions将第一作者的名字和文章来源置顶吧，尊重一下原创

飞哥🐮

能分享出来吗？我们最近也在弄

httprunner V3 的文档，可以看这里
https://ontheway.cool/HttpRunner3DocsForCN/

建议使用相对 x,y 控制，找一个稳定的参照物，这样比 x,y 绝对值稳定性高很多

不讲武德啊

wrk

1

可以看看极客时间上，高楼的性能课程

1、新业务

无历史数据可参考。根据业务特点和预估用户数量，将待测试接口分类，分为低并发接口、高并发接口、核心业务必用接口。

低并发接口：QPS 要求最低 10～100（需要评审），同时在线用户量 x 在线用户使用该功能的概率 x 造成并发压力的概率 x 冗余（比如 1 倍）。
高并发接口：同时在线用户量 x 在线用户使用该功能的概率 x 造成并发压力的概率 x 冗余（比如 1 倍），需要评审。
核心业务必用接口：在低并发或高并发接口公式计算的基础上，建议核心业务必用接口性能冗余 2～3 倍，以此增加核心业务的性能稳定性、降低性能风险。

2、历史业务

根据线上历史数据统计，对应业务场景的接口峰值 QPS、接口比例，再结合目标用户与历史用户的比例，计算出性能目标。

每一个点代表采样点，后面有一段没有，是那段时间的采样出现了延迟，或采样没问题图像展示出现了问题。

建议做高并发测试时，使用命令行进行测试，测试后再用 Jmeter 打开查看报告。

因为采样数据比较消耗资源，图像展示同样也非常消耗资源。

使用 Jmeter 非 GUI 模式，可参考：https://testerhome.com/topics/29517#%EF%BC%884%EF%BC%89%E4%BD%BF%E7%94%A8%E9%9D%9EGUI%E6%A8%A1%E5%BC%8F

看错误信息来判断

1

恭喜要有小宝贝出生了，我家去年出生的