口水记

由于以前的一些债务，某些接口是越来越慢，越来越慢。

最近做了一个新需求，其中有个接口的时间需要13秒。其实最开始是需要20多秒，后面优化了一下，就到13秒了。

但是13秒，这能忍嘛。尽管这个接口只有在用户第一次使用才会请求到（涉及到三个系统），但也忍不了啊，直接劝退一波不忠实用户。

只能是想办法，而且必须想办法。

首先想到的是把一些循环查询去掉。

说干就干，先去看看三个系统的链路，究竟是哪个系统耗时比较久。

结果，其中最底层的系统花费了11秒，那结果稳了呀，把那个11秒优化了，不就ok。

继续往下看，方法中只能通过打日志来看了，究竟是哪个方法，哪行代码耗时。

涉及到9个方法，每个方法耗时1秒多点，这就很难办了，没有明显的短板了。

不方，找一个方法看代码，发现有的方法中有一些遍历，是在循环中去查询数据库，这就有一些办法了。

这里的循环内查询还有点悬机，那就是循环内的查询，是循环对象中json字符串中的某个key的value，虽然处理起来麻烦一点，但最后还是处理好了，空间换时间嘛，总归要处理的。

很快，优化完毕，结果并不理想，差不多优化了2秒左右，还需要8-9秒的时间。

代码中是没有可以优化的点了，因为都是删除、插入、修改，查询都没有，缓存自然不用去想了。

此时想到了另外一点，异步。

因为之前在另外一次优化中有用到异步，一个方法，有调用三个不同外部服务，且顺序并不相关，所以使用了异步，瞬间那个接口便优化了50%以上，结果甚好（注意，异步一定要注意不要翻车，一定先评估好影响，能否异步）。

但是在此次方案中，效果却并不行，由于至少有6个步骤依赖于前面的方法的处理结果，所以无法异步，或者单独把某一两个方法异步，其实意义并不大。

那么又从哪方面入手，此时，我想到了预热。

因为这是一些数据的准备，是对于一些用户的数据初始化，那么，完全可以假设用户已经存在了，把这些数据先准备好，用户来了，直接修改关联关系即可。

说干就干。理论可行，结果也很理想，这里的11秒优化到不到1秒，总体的时间不需要3秒。

至于3秒还能不能优化，我的回答是肯定可以的，但是没必要，这里的3秒你可以理解为一个用户注册的等待数据初始化的时间（一个用户只会有一次这个接口的请求）。

从用户可接受度，以及产品的发展过程、团队角度来说，并没有必要。

用户现在对于3秒注册，接受度很高。其次，产品的重心，目前依然是业务的迭代，所以，团队的重心依然是在业务上。

3秒到1秒的优化，这里的时间成本比前面13秒到3秒的成本甚至还要高，但是起到的团队/公司收益，却不及前面的一成。

要不要做优化，什么时候去做优化，这是一门学问，自己也还有很多要学的。

小结

本次优化的目的是为了提升体验

所以从减少时间入手，找到瓶颈，先解决瓶颈，再去优化边边角角

本次优化并没有去优化边角，只是将瓶颈进行了优化，便完全达到了预期，而且该接口后续的优化，暂时是没有时间去进行，因为还有更多紧急的任务在排着。

不正经语录

• 接口多久算慢，优化到多久算快，不要一概而论
• 不同的优化有不同的目的，目的不同，优化过程也可能不同

声明

本文故事纯属遐想，如有雷同，我是原创。

欢迎转载。
转载请务必注明以下信息。
原作者：谙忆
原文地址：https://copyfuture.com/blogs-details/20200525215110993ktknwg449hzc2re

公众号

更多精彩内容、活动、程序猿的小故事，欢迎扫码关注公众号