关于优化API接口响应速度。。。

今天只是粗略写写，关于这个优化设计的方面很多，接下来再仔细研究研究。

今天发现接口响应很慢，调开发者工具出来查看才发现接口居然耗时2秒左右，然后查了下后台逻辑，发现里面逻辑很多，有调用外部几个接口，还要查询数据库。

两个接口耗时都接近1.5秒了。看了下是查询工作流的接口，看来只能找平台部那边优化了。

剩下的就是优化我们这边系统的查询效率了。

首先需要分析为何慢了

是不是资源层面的瓶颈？

是不是缓存没添加，如果加了，是不是热点数据导致负载不均衡？

是不是有依赖于第三方接口？

是不是接口涉及业务太多，导致程序跑很久？

是不是sql层面的问题导致的等待时机加长，进而拖慢接口？

网络层面的原因？带宽？DNS解析？

代码不行？

未知？

对症下药

资源紧张，加机器，干上去，负载均衡搞起来！

加缓存可以解决的问题都不是什么大问题，存在热点数据可以将某几个热点单独出来用专门的机器进行处理，不要因为局部影响整体（这一次好像不涉及这个）

一方面与第三方沟通接口响应问题，另一方面超时时间注意把控，如果可以非核心业务能异步久异步掉。

把非核心的业务进行异步化操作。记住如果代码层面是非核心业务，但是会影响用户感知，需要慎重决定是否异步。

如果是代码不良导致加锁了，尽量优化索引或sql语句，让锁的级别最小（到行），一般来说到行差不多了。如果是单个sql跑慢了，需要分析是不是索引没加或者sql选的索引错了，索引该加的就加了，该force index也加了。

网路原因，需要找运维人员，单方面比较难有大的优化。

代码确实差，那也无药可救了。毁灭吧！

刚开始以为是机器性能不行，看了下系统负载，发现占用率并不高，好像也不是性能问题。

接着以为是应用优化，但是看了下 JVM 的相关参数和 Java 堆的使用情况，发现都不高，感觉应该是数据库的原因了，当时建表的时候没有建相关的索引。

然后考虑加下索引试试。

加了一个组合索引，还有一个单列索引。

加了之前在代码中加了时间记录，感觉有所提升。

剩下的就是外部接口的耗时了。