接口响应太慢的原因排查

首先判断是否是所有的API接口相应都很慢，还是某个特定的接口相应速度慢，如果所有接口的相应速度都很慢，可能是服务器资源、数据库或者网络流量的问题。 如果只是一个接口比较慢或者某个用户的请求中比较慢 ，那么可能就是业务逻辑或者 SQL 的问题，比如某个sql 索引失效了，进行的是全表的扫描，这个时候我们就需要去进行sql的调优。

1网络层故障的排查

1.我们先用一下ping命令检查一下服务器的连通性以及往返时间。

• 延迟：查看平均 RTT 是否在可接受范围内（通常低于 100ms）。
• 丢包率：查看是否存在数据包丢失，丢包率高会显著影响性能。

2. 查看服务器的资源使用

服务器 CPU 用满了

通过 top 命令查看服务器内存和资源的使用。 %CPU 是 cpu 的使用情况，MEM 是内存的使用情况。 比如有一个服务的 CPU 飙到了 90 多，可能是出现了死锁，或者无限循环了。

如果是 docker 部署的项目，可以用 docker stats 查看 docker 容器占用的内存。

来找到 CPU 占用高的进程，再找到对应的线程。 使用 jstack 查看线程的堆栈信息，这个是 JVM 提供的查看线程信息的工具。可以看到 JVM 的堆栈信息，找到出现问题的具体代码，然后再进行修改。

连接池资源耗尽

可能是 tomcat 的连接池或者是数据库的连接池耗尽，调整业务的线程池参数。

spring:
  datasource:
    hikari:
      maximum-pool-size: 50
      minimum-idle: 10
      connection-timeout: 30000
      idle-timeout: 600000
在配置连接池的时候需要合理设置连接池的大小。多个请求过来数据库的连接池用完了

具体业务代码的排查

查找 慢 sql

针对于具体的接口 ，sql 执行过慢的情况，使用 explain 进行慢 sql 的分析，看 sql 是否走了索引。很多情况下都是索引失效。

这边就可以往 sql 调优去聊了

1. 对于大量的数据查询一定要使用分页查询来限制每次返回的行数。

2.建立联合索引来提高效率等。

3. 使用 explain 分析 sql 查询的执行计划，判断查询是否使用了索引。

从JVM 内存、GC,线程等信息进行考虑

Java 应用程序运行在 JVM 之上，JVM 的性能直接影响 API 接口的响应速度。常见的 JVM 优化策略包括

调整堆内存大小：根据应用的内存需求，合理设置 JVM 的堆内存大小，避免频繁的 GC 操作。

-Xms4g -Xmx4g

使用 G1 GC 垃圾回收器：对于高并发应用，G1 GC 可以减少 Full GC 的停顿时间，提高系统的响应速度。

-XX:+UseG1GC

监控 GC 日志：通过分析 GC 日志，判断是否存在频繁 GC 或长时间停顿的问题。

-XX:+PrintGCDetails -Xloggc:gc.log

设置缓存

如果有些接口在 管理系统下面响应时间比较长，可以将数据缓存起来到 Redis 中，下次查询的时候直接从 Redis 中拿即刻。

系统调用第三方的服务

为第三方的服务设置对应的超时时间，比如三秒钟，如果三秒钟没有响应直接返回，避免长时间的等待。 比如调用阿里的大模型 API，如果存在延迟，三秒钟会有收到 result 直接给用户返回一个空的信息。

对于某些不需要立即返回的第三方服务调用，可以使用异步调用提高系统的响应速度。

熔断和降级

采用微服务的熔断和降级，当第三方服务出现问题时，能够快速返回默认结果，保证系统的稳定性。