本文主要是对这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%的提升。
功能对比
线程的作用
1、dbcp:一个线程:负责心跳,最小连接数维持,最大空闲时间和防连接泄露。
2、druid: 两个线程: 其中一个负责异步创建。一个负责最小连接数的维持。 其中心跳是通过获取连接,来判定是否小于心跳间隔。
3、hikariCP: 三个线程: 其中一个为定时线程,解决最大空闲时间。两个为新建连接和关闭连接。 均是连接池,空闲5s,线程便会关闭。
4、c3p0: 四个线程;三个helperThread (pollerThread),一个定时AdminTaskTimer(DeadlockDetector)。
由于boneCP被hikariCP替代,并且已经不再更新,boneCP没有进行调研。
proxool网上有评测说在并发较高的情况下会出错,proxool便没有进行调研。
druid的功能比较全面,且扩展性较好,比较方便对jdbc接口进行监控跟踪等。
c3p0历史悠久,代码及其复杂,不利于维护。并且存在deadlock的潜在风险。
国内公司连接池使用情况
性能测试(网上查证的,没有亲测)
1、环境配置:
2、获取关闭连接性能测试
测试说明如下:
初始连接和最小连接均为5,最大连接为20。在borrow和return均不心跳检测
其中打开关闭次数为: 100w次
测试用例和mysql在同一台机器上面,尽量避免io的影响
使用mock和连接mysql在不同线程并发下的响应时间
mock性能数据 (单位:ms):
3、mysql性能数据 (单位:ms)
测试结果:
1、mock和mysql连接性能表现差不多,主要是由于初始化的时候建立了连接后期不再建立连接,和使用mock连接逻辑一致。
2、性能表现:hikariCP>druid>tomcat-jdbc>dbcp>c3p0。
3、hikariCP 的性能及其优异。hikariCP号称java平台最快的数据库连接池。
4、hikariCP在并发较高的情况下,性能基本上没有下降。
5、c3p0连接池的性能很差,不建议使用该数据库连接池。
hikariCP性能分析:
1、hikariCP通过优化(concurrentBag,fastStatementList )集合来提高并发的读写效率。
2、hikariCP使用threadlocal缓存连接及大量使用CAS的机制,最大限度的避免lock。单可能带来cpu使用率的上升。
3、从字节码的维度优化代码。 (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的影响
测试数据:
连接池5ms8ms20ms50ms100ms
tomcat-jdbc2,1781,4951,7691,8181,858
c3p03,2373,4514,4885,9947,906
dbcp2,8161,9352,0972,2432,280
hikari2,2991,5461,6821,7511,772
druid2,2971,5511,8001,9772,032
测试结果:
在并发比较少的情况下,每个连接池的响应时间差不多。是由于并发少,基本上没有资源竞争。
在并发较高的情况下,随着并发的升高,hikariCP响应时间基本上没有变动。
c3p0随着并发的提高,性能急剧下降。
pscache性能对比
测试说明:
通过druid进行设置pscache和不设置pscache的性能对比
初始连接和最小连接均为8,最大连接为8。在borrow和return均不心跳检测。并且执行的并发数为8.
查询10w次。查询流程为:1:建立连接,2:循环查询preparestatement语句 3:close连接
测试用例和mysql在同一台机器上面,尽量避免io的影响
测试数据:
cache1,927
not cache2,134
测试结果:
开启psCache缓存,性能大概有10%幅度的提升。可考虑开启pscache.
测试说明:
psCache是connection私有的,所以不存在线程竞争的问题,开启pscache不会存在竞争的性能损耗。
psCache的key为prepare执行的sql和catalog等,value对应的为prepareStatement对象。开启缓存主要是减少了解析sql的开销。