两个数据都很重要。
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
可以看看极客时间上,高楼的性能课程
无历史数据可参考。根据业务特点和预估用户数量,将待测试接口分类,分为低并发接口、高并发接口、核心业务必用接口。
低并发接口:QPS 要求最低 10~100(需要评审),同时在线用户量 x 在线用户使用该功能的概率 x 造成并发压力的概率 x 冗余(比如 1 倍)。
高并发接口:同时在线用户量 x 在线用户使用该功能的概率 x 造成并发压力的概率 x 冗余(比如 1 倍),需要评审。
核心业务必用接口:在低并发或高并发接口公式计算的基础上,建议核心业务必用接口性能冗余 2~3 倍,以此增加核心业务的性能稳定性、降低性能风险。
根据线上历史数据统计,对应业务场景的接口峰值 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
恭喜要有小宝贝出生了,我家去年出生的