前言
前段时间,进行了一次接口调优,现进行简单记录。
需求是这样的,推出了切水果的玩法,用户切水果会爆出分数、虚拟货币,并积攒积分,积分可以兑换相应的商城积分。
需要解决的问题
切完水果之后需要将爆出的积分、虚拟货币等实时性较高的返回。初始期望是能在100个用户同时玩的情况下,每秒两次的调用,测试能保持在平均200ms的响应时长。
每次切水果需要扣除相应的虚拟货币,而且,每次切水果都跟用户之前获取的情况,平台获取的情况相关联。
解决过程
分解需求
在需求评审之后,针对实时性的问题,给出一些方案,如:
- 1.将原有单个水果的操作改为多个水果一次性切除。
- 2.将可以后续不影响主体功能的代码做异步处理。
- 3.将一些使用频繁,但是变更较少的操作改为本地变量。如:爆出概率
- 4.其他前期可以预见的问题。
通过以上的分析,特别是第一条,可以提前让前端做出一些调整,比如怎么样比较合适合并请求多个请求,而不影响用户操作感知。
针对第三条,针对数据变化要通过redis广播通知
code review
首先,组织组内成员对相关功能进行code review,针对一些常见的问题进行发现修改。如:
- 1.循环调用问题
- 2.逻辑错误问题
- 3.边界问题
- 4.能异步的进行异步操作
压测
准备100个用户数据,通过jmeter动态入参,对接口进行压测。
先压测底层dubbo接口,jmeter支持dubbo直接压测,按照100个用户,每隔0.5秒进行调用,进行长时间压测,观察总结结果,根据结果值,查询当前接口可优化的点。
然后压测http接口,模仿真实用户调用,同时,查看房间效果。
为了更便于压测,可以在每一步大的功能点,都加入相应的日志,分析日志可以看到哪里消耗最大。ps:如果大家有开源的更好的方案,欢迎补充。
最终,测试服的压测结果稳定在200ms,基本达到要求,可投入生产。
在压测过程中,也针对用户体验也发现了问题,反馈给产品和运营,可以说一举多得。
上线
因为此功能相对独立,在上线之后,也在线上环境进行了压测,基本稳定在50ms。
总结
在此次调优过程中,经过各方的配合,对细节的排查,提出一些建设性的建议,的确基本保证了基础要求,因为某些原因,该项目虽然上线,但是还未提供给用户,后续开放,也会持续进行关注。
以上的一些调优方案,属于基础的调优方案,如果大佬能够有更好的调优方案,欢迎私聊、评论,相互提高,谢谢。
网友评论