文章转自 https://www.tuicool.com/articles/qayayiM
摘要: 本文主要是对这hikariCP,druid,tomcat-jdbc,dbcp,c3p0几种连接池的详细的功能和性能测试对比,通过这次测试对目前主流的一些连接池做一个全面的对比,从而给业务系统一个最佳的推荐。而唯品会venus-data支持三种连接池DBCP、C3P0、DRUID,其中C3P0作为默认的连接池。因此需要针对现状,研发一种分布式数据库连接池。
测试结论
- 性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免锁竞争。
- druid功能最为全面,sql拦截等功能,统计数据较为全面,具有良好的扩展性。
- 综合考虑到目前venus已经支持druid且hikariCP并未发现有太多大规模的生产实践的案例,后续将推荐使用druid并把codegen生成的代码默认连接池为druid。
- 可开启prepareStatement缓存,对性能会有大概10%的提升。
功能对比
功能 | dbcp | druid | c3p0 | tomcat-jdbc | HikariCP |
---|---|---|---|---|---|
是否支持PSCache | 是 | 是 | 是 | 否 | 否 |
监控 | jmx | jmx/log/http | jmx,log | jmx | jmx |
扩展性 | 弱 | 好 | 弱 | 弱 | 弱 |
sql拦截及解析 | 无 | 支持 | 无 | 无 | 无 |
代码 | 简单 | 中等 | 复杂 | 简单 | 简单 |
更新时间 | 2015.8.6 | 2015.10.10 | 2015.12.09 | 2015.12.3 | |
特点 | 依赖于common-pool | 阿里开源,功能全面 | 历史久远,代码逻辑复杂,且不易维护 | 优化力度大,功能简单,起源于boneCP | |
连接池管理 | LinkedBlockingDeque | 数组 | FairBlockingQueue | threadlocal+CopyOnWriteArrayList | |
线程 | 1个线程(心跳) | 2个线程 | 4个 | 3个 |
线程的作用
- dbcp:一个线程:负责心跳,最小连接数维持,最大空闲时间和防连接泄露。
- druid: 两个线程: 其中一个负责异步创建。一个负责最小连接数的维持。 其中心跳是通过获取连接,来判定是否小于心跳间隔。
- hikariCP: 三个线程: 其中一个为定时线程,解决最大空闲时间。两个为新建连接和关闭连接。 均是连接池,空闲5s,线程便会关闭。
- 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的开销。
来源:oschina
链接:https://my.oschina.net/u/4321881/blog/4049854