原文 http://blog.xujin.org/mw/dcp-test/
摘要: 本文主要是对这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在不同线程并发下的响应时间
image
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 |
image
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的影响
image
测试数据：
| 连接池 | 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的开销。
