最近有个项目进行压力测试；现场压测人员反馈tps不稳定，两三分钟就直线下降。
数据库：数据库：分布式mysql（黑盒子，只提供了数据库连接地址）
应用服务器:Tomcat8*3集群
1、检查应用SQL执行效率，结合MySQL给出的慢SQL和应用的日志
有部分SQL执行效率较低，主要是索引没有使用好，加上索引。
继续测试，MySQL没有慢日志了，但随着时间推移，tps下降还是比较明显。
2、MySQL没有满日志，检查应用日志，jdbc执行SQL的时间却较长，而且随着时间的推移响应时间会延长。
会不会是表中数据量的增长导致？DBA反馈MySQL没有慢日志，相关SQL在数据库连接工具中响应又很快。
3、刚开始时响应时间较快，然后响应时间逐渐上升（5s+）；TPS也逐渐下降(90左右下降到平均30)。
从jdbc日志来看，响应慢的SQL基本上是update和insert；查询响应较快。
由于测试的是登录退出场景，会不会是数据的更改和查询间隔时间太短？
脚本中加一点思考时间，隔开登录和退出操作，然后加大虚拟用户数量，保证tps不变（约85）。
当3个server一起测试的时候，tps刚开始会慢慢降低，到半小时左右是基本稳定了，但响应时间半小时后依旧上升，根本刹不住车！
4、测试时发现，开始测试时响应较快，连接池中的连接数较低；
随着测试的进行，响应时间变长，连接池中的连接数也变多了（用netstat查看的连接数量）。
是响应时间变长导致的连接数变多？从数据库DBA反馈没有超过1s的慢SQL来看，如果存在这个可能性也不会是数据库端造成的，因为测试几小时后jdbc端的响应时间部分SQL已稳定在4s+。多余的时间应该是消耗在jdbc和数据库中间件之间了。
5、有没有可能是连接数变多导致的响应时间延长？
多次测试后发现，每个server的连接数在30以下时，响应时间较为正常，那就限定连接池的maxactive为30.
重启测试后发现，连接池数量不够用。
6、果断将DBCP连接池切换为高性能异步连接池jdbc pool；
配置好maxTotal、maxIdle等参数；再次进行测试时发现怎么响应时间还是在变长；查看连接数，哎？都60往上走了！
异步连接池要靠idle的连接来满足异步的性能，而idle的连接数量还和线程等有关……
先把这些参数配置降下来再说吧。
7、逐步减少maxTotal、maxIdle然后测试，maxTotal为10左右，maxIdle在5以下，然后结合连接回收参数才能满足连接数量稳定在20左右。
按照该参数进行测试，tps保持稳定（90左右），没有下降趋势，平均响应时间也在0.2s左右，保持稳定。
所以，上面猜测的连接数过多导致响应时间延长的猜测应该是正确的。
以下是猜测：
那么，这个锅是谁的呢？应该是分布式数据库的中间件。
分布式数据库的中间件应该是这样的逻辑吧：消息中间件+数据库连接池；
应用连接池中的连接只是和数据库中间件连通，数据库中间件持有的是真正的数据库连接，该连接数量应该是被限制了大小的（上面的测试大约是100的限制）。
当队列的量大于了真实的数据库连接数，就需要排队等候真实连接了。
为什么响应较慢的是update和insert的SQL呢？
而一般应用中查询SQL的量是远大于更新SQL的量的，排队中的SQL查询请求较多，可能导致中间件连接池中查询连接变多，而总量限制的情况，更新连接就会变少，从而导致更新请求等待队列更长。
大概是没有相应优先级设置或是没有设置优先级吧？