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