单一接口优化过程全记录(主要涉及Redis)

时间:2022-12-06 16:05:18

接口优化过程记录

问题背景

某个接口耗时长(247ms),但里面逻辑不算复杂,只进行了简单的对象引用以及操作了多次Redis

步骤1:链路追踪,确定业务耗时点

接口里通过链路追踪以及日志查询发现主要是操作Redis的这条链路耗时变长

步骤2:从Redis找问题,列出可能点

原因可能是:

  1. Redis本身存在问题,可能是命令复杂度、IO、连接数不够、过载等
  2. 网络原因,获取连接或者是数据传输耗时

经测试发现以下这些问题

  • 使用本机ping服务器,网络延迟大概在42ms(ping内网<1ms,ping公司线上环境7ms),属于 高延迟
    单一接口优化过程全记录(主要涉及Redis)

  • 内部逻辑对获取Redis连接进行耗时记录,发现除首次获取连接需30ms,后续获取连接耗时 <1ms,

  • 内部对Redis的一个get操作需要47ms(高耗时)

步骤二总结:

  1. 调用方与客户端的网络高延迟
  2. 普通的get操作需要47ms不排除Redis本身存在问题,需要继续排查

步骤3:从Redis内部排查

3.1从服务器内部查看延迟峰值

由于Redis是使用Docker搭建,在虚拟化环境可能会差一些,不过还是先查看延迟峰值以及平均响应时 间

100秒内测试结果

单一接口优化过程全记录(主要涉及Redis)

60秒内测试结果

单一接口优化过程全记录(主要涉及Redis)

从测试数据可以看出

  1. 在100秒时,最大延迟为16ms,处理了1,762,165,232次命令平均响应时间为0.053ms
  2. 在60秒时,最大延迟为14ms,处理了1,066,484,486次命令平均响应时间为0.056ms

总结:从这一测试数据看单一get命令是不会到40+ms

3.2设置慢命令时间

通过给Redis设置slowlog时间为5ms,从业务代码里操作set和get命令各200条,均无发现slowlog。

3.3命令复杂度过高(略)

接口里使用的命令只是简单的get,set操作,并不是SORT、SUNION等聚合类容易导致操作延迟变大的 命令。

且O(N)里的N值并不大,也不需要花费很多时间在数据协议的组装和网络传输过程中。

所以该指标不做测试。⚠ Ps:若是想测试该指标也可用slowlog进行排查。

3.4bigkey(略)

接口里操作的都不是bigkey,该指标不做测试。有需要可先使用redis命令扫描bigkey。注意:扫描时与 上述提到的延迟峰值都会使Redis的OPS突增。

3.5集中过期(略)

该Redis里并没有过多数据,该指标不做测试。

3.6实例内存达到上限

从数据上来看,内存并没有使用很多。

3.7fork耗时严重(略)

如3.5中所说,该指标不做测试

3.8连接数问题

从springboot里使用了nio开发的lettuce Redis线程池,当设置连接数为500时,在代码层面开启多个线 程一直跑,Redis客户端连接数可以达到峰值,所以这块暂时没有问题。

暂时总结

根据上述数据总结出99%是网络问题造成的获取数据延迟。当然还有很多指标都没有列举,例如:是否 开启内存大页、是否开启AOF造成Redis、或者是是否使用Swap等。由于服务器的Redis也算比较简 单,这些也就默认是正常了

后续执行

后续可以再继续监控

  1. 观察连接数,是否有频繁的短连接消耗
  2. 以及对Redis的各个指标进行监控