背景：一个接口，本身有一定的逻辑，但是不复杂，主要是处理数据，不涉及到数据库操作，但是内部调用两个接口。基本逻辑是先调用BI的一个接口获取到基础数据，在本地处理完数据在根据classid去业务系统查班级，查完的数据在本地处理，返回结果。其中业务系统的接口是老接口，不会存在性能问题，BI的接口是我先压测的，也没性能问题，而本地并无复杂操作，所以接口理论上是不会有性能问题的，但压测的结果却很慢。
压测过程中查看了可以看的地方，没看到异常（其实有，当时没看到），而且涉及到三个系统，没头绪的话查起来会很浪费时间，于是找开发把主要逻辑加上了时间戳。
结果如下，这是grep出时间最长的。
代码如下，主要都是redis的操作，进去看逻辑。
逻辑：
不一一看了，这个方法里面主要是对redis的操作，涉及到4个get和4个set，redis的性能是非常好的，之前测试一个4C的服务器，tps轻松上万，单个get或者set只有几毫秒。所以说这里不应该这么慢。看上面的时间都已经几百多毫秒。所以要看下redis的问题，找到redis配置，如下，这是spring boot 对redis连接池的配置，而且开发应该用的默认配置，明显很小，改大之后再测试。
结果如下，时间明显少了很多，服务器CPU也已经上去，tps由一百多到达了四百多。问题确定。
回过头来再看这个问题，可以明显的感觉到做性能测会代码的重要性，很多问题，在代码层很容易定位，至少很容易缩小范围。
再来看看不用代码怎么定位问题。下面这段是我打印的两次线程信息，1.txt是第一次，2.txt是第二次的线程信息，明显看到第一次中waiting有136个线程，而第二个只有61个
查看具体线程信息，明显可以看出来是在等待redis线程池。
再看下这个对比，就更明显了。第二次已经没有等待redis连接池的线程了。
