数据库链接池性能测试(hikariCP,druid,tomcat-jdbc,dbcp,c3p0)

本文主要是对这hikariCP,druid,tomcat-jdbc,dbcp,c3p0几种链接池的详细的功能和性能测试对比,经过此次测试对目前主流的一些链接池作一个全面的对比，从而给业务系统一个最佳的推荐。

测试结论

1. 性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免锁竞争。
2. druid功能最为全面，sql拦截等功能，统计数据较为全面，具备良好的扩展性。
3. 综合考虑到目前venus已经支持druid且hikariCP并未发现有太多大规模的生产实践的案例，后续将推荐使用druid并把codegen生成的代码默认链接池为druid。
4. 可开启prepareStatement缓存，对性能会有大概10%的提高。

功能对比

功能	dbcp	druid	c3p0	tomcat-jdbc	HikariCP
是否支持PSCache	是	是	是	否	否
监控	jmx	jmx/log/http	jmx,log	jmx	jmx
扩展性	弱	好	弱	弱	弱
sql拦截及解析	无	支持	无	无	无
代码	简单	中等	复杂	简单	简单
更新时间	2018.1.13	2018.1.14	2017.5.4		2018.1.14
特色	依赖于common-pool	阿里开源，功能全面	历史久远，代码逻辑复杂，且不易维护		优化力度大，功能简单，起源于boneCP
链接池管理	LinkedBlockingDeque	数组		FairBlockingQueue	threadlocal+CopyOnWriteArrayList
线程	1个线程(心跳)	2个线程	4个		3个

线程的做用

1. dbcp：一个线程：负责心跳，最小链接数维持，最大空闲时间和防链接泄露。
2. druid: 两个线程： 其中一个负责异步建立。一个负责最小链接数的维持。 其中心跳是经过获取链接，来断定是否小于心跳间隔。
3. hikariCP: 三个线程： 其中一个为定时线程，解决最大空闲时间。两个为新建链接和关闭链接。 均是链接池，空闲5s，线程便会关闭。
4. c3p0: 四个线程；三个helperThread （pollerThread）,一个定时AdminTaskTimer（DeadlockDetector）。 
   因为boneCP被hikariCP替代，而且已经再也不更新，boneCP没有进行调研。 
   proxool网上有评测说在并发较高的状况下会出错，proxool便没有进行调研。 
   druid的功能比较全面，且扩展性较好，比较方便对jdbc接口进行监控跟踪等。 
   c3p0历史悠久，代码及其复杂，不利于维护。而且存在deadlock的潜在风险。

国内公司链接池使用状况

公司	数据库链接池
58同城	本身开发
滴滴	druid dbcp
知果果	druid
慧聪	druid dbcp
起步科技	dbcp 和 druid
亚信	hikariCP
惟品会	dbcp,druid,c3p0（默认）

性能测试

环境配置:

CPU	Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50GHz，24core
msyql version	5.5.46
tomcat-jdbc version	8.0.28
HikariCP version	2.4.3
c3p0 Version	0.9.5-pre8
dbcpVersion	2.0.1
druidVersion	1.0.5

获取关闭链接性能测试

测试说明以下:

• 初始链接和最小链接均为5，最大链接为20。在borrow和return均不心跳检测

• 其中打开关闭次数为: 100w次

• 测试用例和mysql在同一台机器上面，尽可能避免io的影响

• 使用mock和链接mysql在不一样线程并发下的响应时间

mock性能数据 (单位:ms)

链接池	5ms	20ms	50ms	100ms
tomcat-jdbc	442	447	1,013	1,264
c3p0	4,480	5,527	7,449	10,725
dbcp	676	689	867	1,292
hikari	38	33	38	30
druid	291	293	562	985

mysql性能数据 (单位:ms)

链接池	5ms	20ms	50ms	100ms
tomcat-jdbc	436	453	1,033	1,291
c3p0	4,378	5,726	7,975	10,948
dbcp	671	679	897	1,380
hikari	96	82	87	78
druid	304	424	690	1,130

测试结果：

• mock和mysql链接性能表现差很少，主要是因为初始化的时候创建了链接后期再也不创建链接，和使用mock链接逻辑一致。
• 性能表现：hikariCP>druid>tomcat-jdbc>dbcp>c3p0。
• hikariCP 的性能及其优异。hikariCP号称java平台最快的数据库链接池。
• hikariCP在并发较高的状况下，性能基本上没有降低。
• c3p0链接池的性能不好，不建议使用该数据库链接池。

hikariCP性能分析：

• hikariCP经过优化(concurrentBag，fastStatementList )集合来提升并发的读写效率。
• hikariCP使用threadlocal缓存链接及大量使用CAS的机制，最大限度的避免lock。单可能带来cpu使用率的上升。
• 从字节码的维度优化代码。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes ）让方法尽可能在35个字节码一下，来提高jvm的处理效率。

查询一条语句性能测试

测试说明：

• 初始链接和最小链接均为8，最大链接为8。在borrow和return均不心跳检测
• 测试在不一样并发下查询的次数为10w次的总耗时对比，操做步骤为 1：打开链接 2：执行 ：select 3. 关闭链接
• 测试用例和mysql在同一台机器上面，尽可能避免io的影响

测试数据：

链接池	5ms	8ms	20ms	50ms	100ms
tomcat-jdbc	2,178	1,495	1,769	1,818	1,858
c3p0	3,237	3,451	4,488	5,994	7,906
dbcp	2,816	1,935	2,097	2,243	2,280
hikari	2,299	1,546	1,682	1,751	1,772
druid	2,297	1,551	1,800	1,977	2,032

测试结果：

• 在并发比较少的状况下，每一个链接池的响应时间差很少。是因为并发少，基本上没有资源竞争。
• 在并发较高的状况下，随着并发的升高，hikariCP响应时间基本上没有变更。
• c3p0随着并发的提升，性能急剧降低。

pscache性能对比

测试说明：

• 经过druid进行设置pscache和不设置pscache的性能对比
• 初始链接和最小链接均为8，最大链接为8。在borrow和return均不心跳检测。而且执行的并发数为8.
• 查询10w次。查询流程为：1：创建链接，2：循环查询preparestatement语句 3：close链接
• 测试用例和mysql在同一台机器上面，尽可能避免io的影响

测试数据：

cache	1,927
not cache	2,134

测试结果：

• 开启psCache缓存,性能大概有10%幅度的提高。可考虑开启pscache.

测试说明：

• psCache是connection私有的，因此不存在线程竞争的问题，开启pscache不会存在竞争的性能损耗。
• psCache的key为prepare执行的sql和catalog等，value对应的为prepareStatement对象。开启缓存主要是减小了解析sql的开销。