一、问题背景

采样接口的平均耗时2.4s，调用次数为2次。

注意，左侧的接口响应时间是指平均响应时间。（这一点很多大佬都吐槽过，不知道为什么他们死活不改）

image.png

响应时间和调用次数.png

从第二张图，也可以印证该接口的调用次数和响应耗时，个人觉得，左侧的接口响应时间应该换为P90线的响应时间。

原因是：在调用调用量大的时候，耗时为4.2秒的请求会被淹没，在左侧接口列表中发现不了耗时慢的。

查看最近6小时，耗时慢的接口调用都被淹没了吧.png

二、发现问题

该服务在重启后，第一次调用是在2022-10-28 13:48:43，耗时4.2秒；第二次调用是在2022-10-28 13:48:45，耗时降低至576毫秒。

响应时间为什么会相差这么大？？

image.png

如果方法栈不足以定位代码问题，请继续查看线程剖析结果.png

耗时4.2秒.png

耗时576毫秒.png

看下耗时大的1800毫秒，慢在哪个方法

image.png

io.lettuce.core.RedisClient.connect( ):207 [1400ms]
可以看到，程序和redis的连接耗时1400毫秒。在第二次及以后就不用再进行redis连接了，所以接口的耗时一下子就降下去了。

不知道为什么arms的实际耗时是4244毫秒，而监听耗时却是2300毫秒。增加的那2秒跑哪里去了？？

三、总结

我们都知道，程序在和数据库建立连接的时候，是最耗时的。希望本文能够给你一个直接的耗时慢的体验现场。

在配置redis连接池（包括mysql等数据库），特别关注它的连接数

四、附录

redis配置

# 连接超时时间
spring.redis.timeout=5000
# 连接池最大连接数（使用负值表示没有限制）
spring.redis.lettuce.pool.max-active=3
# 连接池中的最小空闲连接
spring.redis.lettuce.pool.min-idle=2
# 连接池中的最大空闲连接
spring.redis.lettuce.pool.max-idle=3
# 连接池最大阻塞等待时间（使用负值表示没有限制）
spring.redis.lettuce.pool.max-wait=-1
#在关闭客户端连接之前等待任务处理完成的最长时间，在这之后，无论任务是否执行完成，都会被执行器关闭，默认100ms
spring.redis.lettuce.shutdown-timeout=100

spring boot 默认使用的redis连接组件是luttuce，而不是jedis

# 下面是无效的配置
  redis:
    jedis:
      pool:
        max-active: 1000  # 连接池最大连接数（使用负值表示没有限制）
        max-wait: -1ms      # 连接池最大阻塞等待时间（使用负值表示没有限制）
        max-idle: 10      # 连接池中的最大空闲连接
        min-idle: 5       # 连接池中的最小空闲连接