订单详情优化思路
线上查询订单详情平均耗时 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服务, 在同一个局域网网络进行远程调用耗时并不会很夸张,
性能瓶颈: 从结果看出, 几十个串行任务, 加起来一共需要这么久, 性能瓶颈在于串行任务太多, 有的查询不太合理,
下面针对上图耗时方法进行优化
优化方式一 (并行, 需注意服务器资源):
针对必定查询的接口, 将数据之间依赖性很少的远程调用(查询数据库)接口, 改为并行
优化方式二: 修改一些多次循环调用的
例如这里线上的, 多次调用获取子任务, 多次获取图片
修改图片为批量查询后的结果:
另一个子任务的批量查询需要别的业务线配合
优化方式三: 缓存
考虑是否可缓存, 图片、问题列表、大数据查询用户指派率、 或者一些不经常修改的数据进行缓存
优化方式四: 减少不必要查询
优化方式五: 将没有依赖的数据查询拆出来成为接口让前端异步调用
到此优化方案暂时结束
注意使用异步进行优化时候, 需要注解别共用公共线程池、 如果需要立即响应的功能, 选择不存储任务队列, 拒绝策略走调用者执行