我们公司的产品,新增单据的接口访问有限制,限制 2s 内不能重复访问,而且登录的 token 不能重复使用,这样并发的时候接口就都报错了,没法正常跑通,请问性能大神有没有这种情况类似的解决方案啊?
那就没必要压了。
或者像楼下说的这样,这种情况主要是针对单用户的。比如我们也是限制单用户三秒内不能重复下单。
这种情况只能用海量用户去压,而不能单用户重复去压
200 个用户来做 200 并发?这样做吗?模拟的是 200 个用户同时登录操作?这实际就是 200 个用户同时了,不是压的吧。。??
看用户需求啊,比如 200 并发就先注册 200 个用户,然后 200 用户分别取 token。用户名和 token 作为参数化,然后设置集合点,进行并发测试。当然如果开发配合的话做个开关最方便。
这种情况需要开发改啊?我们小团队性能这块刚开始探索
让开发给你加一个白名单去掉限制
那就没必要压了。
或者像楼下说的这样,这种情况主要是针对单用户的。比如我们也是限制单用户三秒内不能重复下单。
这种情况只能用海量用户去压,而不能单用户重复去压
限制 2s 内不能重复访问,这个应该是针对单个用户而言嘛
所以应该是要提前登录一批测试账号获取到 token,然后再来压测吧?
对 token 服务做一个 mock,然后就可以进行压测了
这种有必要做压测么?
我们后端的接口 responseBody 中也是有个 code 字段,返回 code_200 或 code_500 这些,但是接口有依赖数据这种情况,因为单接口的访问限制了并发,所以并发时上层接口没成功返回数据,下层接口也就获取不到数据,这样还可以视为有效压力吗?就比如说创建单据的接口,并发时接口失败了没有实际的创建单据,也就没有数据的插入,但是接口响应 http 状态码是 200 的,而且这种情况我观察到平均响应时间貌似要比正常的短
test
不知道你们后端是怎么响应的,不过我司是正常响应 http 状态码 200,responseBody 里面还有个 errorCode,比如这种情况为 2020,那么你做性能的时候,肯定需要判断当前请求是否成功,可以在判断 http 状态码为 200 的前提下再判断 errorCode。我这边有好几种这样的场景,我是定义一个比如 code_list,把这种业务限制的 code 丢进去,校验时判断如果当前的 errorCode 存在 code_list 中时,不向统计中心上报此条数据(可以根据这个业务场景的代码覆盖链条深不深来决定是否上报这条数据,比如如果在最外面的 api 网关层没做过多的业务判断就直接返回,这种请求可以直接丢弃,如果是走到了业务链最后端之后才返回,那么此条数据可以视为有效压力,就可以保留上报)