分享removeAbandonedTimeout中间件参数调优经验

背景：***系统 生产环境健康管理咨询文章接口响应时间超过300s，且后台大量报：

测试环境重现：健康管理咨询文章接口总体数据130条数据左右，systemCode代表查询的系统，目前主要有两个系统科技个险（kjgx）和太保安联科技个险每页显示3条数据（总数据条数为130条左右，则page字段有40页可供随机查询）太保安联每页显示10条数据（总数据条数为130条左右，则page字段有13页可供随机查询）
接口：page=${pagesize}&size=3&systemCode=kjgx&taglibCode=TAGLIB0046 对要查询的页数进行随机参数化
测试环境按照10/100/1000梯度并发进行测试，当1000并发此接口的响应时间达到了22s,且成功率低于仅为23%，系统大量报超时，但是未发现生产报错
项目组排查原因，之前程序里分页数据查询是先查询出所有数据，循环数据做数据处理，再进行分页，影像性能，分页逻辑改为查询的时候进行分页，然后从分页数据里取出数据，再循环处理，优化后1000并发响应时间下降到3s左右，成功率上升到92%，但是仍未复现生产的报错，为了验证生产的问题是否为此问题优造成的，测试做了几组比较测试：

测试环境同步生产包（未优化）以及镜像，在removeAbandonedTimeout=300情况下，测试结果成功率10%，响应时间28s左右，但是未出现生产报错；
测试环境同步生产包（未优化）以及镜像，在removeAbandonedTimeout=20情况下，测试结果成功率低于10%，响应时间32s左右，出现生产报错；
测试环境包优化后（昨晚逻辑优化），在removeAbandonedTimeout=20情况下，测试结果成功率低90%左右，响应时间3ss左右，未出现生产报错。
总结下来就是当接口响应时间>removeAbandonedTimeout时，测试环境会重现生产报错，只要解决响应时间较长的问题，就可以避免此问题，通过对比压测，调优前后，此接口的耗时有明显改善，因此可以初步确定此问题就是引起生产问题的原因。

 

rmoveAbandoned参数含义：

设置了rmoveAbandoned=true 那么在getNumActive()快要到getMaxActive()的时候，系统会进行无效的Connection的回收，回收的 Connection为removeAbandonedTimeout(默认300秒)中设置的秒数后没有使用的Connection，

JDBC连接池一些常用的参数含义：

初始化连接 
dataSource.initialSize=10 

最大空闲连接 
dataSource.maxIdle=20 

 最小空闲连接 
dataSource.minIdle=5 

最大连接数量 
dataSource.maxActive=50 

是否在自动回收超时连接的时候打印连接的超时错误 
dataSource.logAbandoned=true 

是否自动回收超时连接 
dataSource.removeAbandoned=true 

超时时间(以秒数为单位) 
dataSource.removeAbandonedTimeout=180 

 超时等待时间以毫秒为单位 6000毫秒/1000等于60秒
dataSource.maxWait=1000