性能常识 遇到个问题,涉及到事件回调的功能如何做压力测试

wchzs · 2023年02月28日 · 最后由 底层贫困人员 回复于 2023年03月02日 · 6002 次阅读

现在在做一个业务系统的测试,系统功能是基于企业微信开放平台提供的 api 接口,这个系统需要做压力测试,评估下来能产生压力的场景都是企业微信的一些事件回调功能,这种功能性能场景应该怎么做压测呢

比如系统会实时获取企业成员的聊天记录,这个功能接的是企微的事件回调,生产环境会频繁产生大量聊天记录,这个功能如果要做压测有什么方法吗

共收到 13 条回复 时间 点赞
仅楼主可见

后端屏蔽微信接口就行了。
如果你们的业务逻辑完全都是调的微信接口(就是纯粹的转发接口),那我觉得其实压测意义不大。

一般会有两种办法:

  1. Mock 数据,然后只验证自己处理回调接口的性能,默认企微的接口是没有问题的。
  2. 看看企微有没有类似沙箱的环境,让你们压。

有个小疑问,你们获取成员聊天记录是想干什么。。。

CKL的思考 回复

有没有一种可能,聊天记录是加密的?只不过会把聊天记录储存在企业本地。

注意哦

企业微信的回调 API 都是有限流的哦

CKL的思考 回复

和开发讨论了下,模拟企微对系统发起请求理论可行,但请求会涉及到各种加密,估计难点就是如何构造请求了

可能是因为业务带销售性质,对聊天记录比较敏感吧。。

Smobee 回复

虚拟出一个接口估计不太合适吧,得到的结果只能证明虚拟接口的性能

Kilmer 回复

嗯,压调用企微接口的场景的时候会注意这个的

徐汪成 回复

是企微请求我们系统,把数据给我们。。就怕数据给的多了快了把系统给弄崩了

这个回调本质上就是企业微信主动调回你们系统提供的指定接口吧?这样的话直接模拟企业微信发起请求就好啦。

系统设计上,可以把所有回调的消息直接甩消息队列做削峰处理,具体入库存储由另一个消费者服务从队列里取数据逐个进行,也可以比较有效避免消息太多系统崩掉。

wchzs 回复

如果是企微回调你们的接口主动上传数据,那实时性要求不高的话,如 10 楼所说,直接用 MQ 会好点,性能压力会极大缓解。
至于模拟加密麻烦。。。这个应该不算什么问题吧,没难度。

你这是压测企业微信还是压测你们的系统

直接上 kafka 吧

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册