本文通过分析一个接口在压测中出现的性能问题，揭示了Redis连接池配置过小对系统性能的影响。接口内部涉及多个Redis操作，原本预期性能良好，但在压测中发现响应时间较长。通过添加时间戳跟踪，发现Redis操作耗时过高。进一步检查Redis连接池配置，发现其设置较小，调整后性能显著提升，TPS从一百多提升至四百多。这强调了性能测试中代码层面的诊断价值，并通过线程信息对比确认了问题在于等待Redis连接池的线程过多。
背景：一个接口，本身有一定的逻辑，但是不复杂，主要是处理数据，不涉及到数据库操作，但是内部调用两个接口。基本逻辑是先调用BI的一个接口获取到基础数据，在本地处理完数据在根据classid去业务系统查班级，查完的数据在本地处理，返回结果。其中业务系统的接口是老接口，不会存在性能问题，BI的接口是我先压测的，也没性能问题，而本地并无复杂操作，所以接口理论上是不会有性能问题的，但压测的结果却很慢。
压测过程中查看了可以看的地方，没看到异常(其实有，当时没看到)，而且涉及到三个系统，没头绪的话查起来会很浪费时间，于是找开发把主要逻辑加上了时间戳。
结果如下，这是grep出时间最长的。
代码如下，主要都是redis的操作，进去看逻辑。
逻辑：
最低0.47元/天 解锁文章
210
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
