订单详情优化思路
线上查询订单详情平均耗时 635ms,
线上服务器资源如下:
线上内部的调用链路
从接口层面上分析:
主要耗时的查询在, 查询订单详情: 200+ms, 加上其余的一些查询, 一共是650ms左右
接口返回中的所有的数据都是基于, 订单详情数据库接口来的,
也就是
/orderDetailService/orderDetail (请求数:447821 / 响应时间:230.6ms / 错误数:0)
, 得获取到该接口的数据才能进行其他数据的组装。而其余的40多个其他数据接口(查询数据库或者NoSql)平均耗时都在50ms以内, (PS: 有的一些接口是必须符合条件才会去查询)
性能问题在与, 后面的一大堆接口都是串行方式在运行, 一大堆接口串行耗时加起来就是600+ms的
预测的优化目标是, 230ms + 200ms (其他业务处理), 优化该接口响应时间为500ms以内
优化方式:
- 优先从查询订单详情的接口入手, 看看SQL有没有可能进一步优化, 优化成为200ms内响应
- 从4核心的服务器资源来看, CPU可利用还能进一步提升, 但需注意别打太满, 以免影响到其他接口的性能
- 除了基础数据, 其他一些平均50ms内的一定会查询或者查询次数平均较多的, 如果接口之间没有依赖, 可修改为并行方式
- 或者一些基本不会变动的数据, 使用缓存, 或者一些频繁查询耗时较长的使用缓存, 通过一个基础接口可以判断缓存中的数据是否是最新的, 非最新的重新缓存, 将缓存利用率和命中率提升
根据调用次数可以分为: 一些必定查询的接口, 和一些非必定查询的接口,
测试环境通过 性能分析工具(神器)–XRebel 或者环境部署的skywalking)
环境部署的
skywalking
从上面图可以看出主要耗时的方法, 以及远程调用的路径,
也可以看出, 本地运行的web服务远程调用其他服务器的接口, 耗时挺久的 一共需要2秒多,
而在测试环境部署的web服务, 在同一个局域网网络进行远程调用耗时并不会很夸张,
性能瓶颈: 从结果看出, 几十个串行任务, 加起来一共需要这么久, 性能瓶颈在于串行任务太多, 有的查询不太合理,
下面针对上图耗时方法进行优化
优化方式一 (并行, 需注意服务器资源):
针对必定查询的接口, 将数据之间依赖性很少的远程调用(查询数据库)接口, 改为并行, 并且配合配置中心加上开关以便随时可以恢复以前串行的方案
同时可以配合好, 动态刷新配置属性的配置中心来做到, 实时开关并行或者恢复串行
优化方式二: 修改一些多次循环调用的
例如这里线上的, 多次调用获取子任务, 多次获取图片
修改图片为批量查询后的结果:
另一个子任务的批量查询需要别的业务线配合
优化方式三: 缓存
考虑是否可缓存, 图片、问题列表、大数据查询用户指派率、 或者一些不经常修改的数据进行缓存
优化方式四: 减少不必要查询
修改成为, 让前端从列表中取出关键
orderFrom
参数传过来,
同时兼容其他入口进入的订单详情可以不传, 并且配合配置中心加上开关以便随时可以恢复以前串行的方案
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yn0gQB1I-1666231548436)(https://jiqmwlmd0v.feishu.cn/space/api/box/stream/download/asynccode/?code=NzJiMWQzYmU4MDI5YzA1MTJjMTcyOWFlN2I3Nzc1MmNfOU5kNlhDNmJtdlExT2FUREQ5Zzdxd1R5SENhdjFyaFNfVG9rZW46Ym94Y25yUGRLOEx6YzRJUTRvcXdkekcwc3NkXzE2NjYyMjk3ODU6MTY2NjIzMzM4NV9WNA)]
优化方式五: 将一些重复查询调用的结果重复使用
优化方式六: 将一些已经暂停使用的业务加上条件是否查询调用
使用这个优化方式, 最好配合配置中心
@Value("${not.query.prepareDetail:true}")
一起使用,可以通过修改配置属性变成立即恢复原来未优化逻辑
优化方式七: 将没有依赖的数据查询拆出来成为接口让前端异步调用
到此优化方案暂时结束
注意使用异步进行优化时候, 需要注解别共用公共线程池、 如果需要立即响应的功能, 选择不存储任务队列, 拒绝策略走调用者执行
补充优化上线后的结果:
还有个前端增加传递参数的没上, 即优化方式四, 前端上线增加传递参数后, 大概还能少30ms左右