接口测试用例怎么设计的（单一接口优化过程全记录（主要涉及Redis））
接口优化过程记录
问题背景
某个接口耗时长（247ms） ，但里面逻辑不算复杂 ，只进行了简单的对象引用以及操作了多次Redis
步骤1：链路追踪 ，确定业务耗时点
接口里通过链路追踪以及日志查询发现主要是操作Redis的这条链路耗时变长
步骤2：从Redis找问题 ，列出可能点
原因可能是：
Redis本身存在问题 ，可能是命令复杂度 、IO 、连接数不够 、过载等 网络原因 ，获取连接或者是数据传输耗时经测试发现以下这些问题
使用本机ping服务器 ，网络延迟大概在42ms（ping内网<1ms ，ping公司线上环境7ms） ，属于 高延迟
内部逻辑对获取Redis连接进行耗时记录 ，发现除首次获取连接需30ms ，后续获取连接耗时 <1ms,
内部对Redis的一个get操作需要47ms（高耗时）
步骤二总结：
调用方与客户端的网络高延迟 普通的get操作需要47ms不排除Redis本身存在问题 ，需要继续排查步骤3：从Redis内部排查
3.1从服务器内部查看延迟峰值由于Redis是使用Docker搭建 ，在虚拟化环境可能会差一些 ，不过还是先查看延迟峰值以及平均响应时 间
100秒内测试结果
60秒内测试结果
从测试数据可以看出
在100秒时 ，最大延迟为16ms ，处理了1,762,165,232次命令平均响应时间为0.053ms 在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也算比较简 单 ，这些也就默认是正常了
后续执行
后续可以再继续监控
观察连接数 ，是否有频繁的短连接消耗 以及对Redis的各个指标进行监控创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！