firemail

标题: 数据库连性池性能测试(hikariCP,druid,tomcat-jdbc,dbcp,c3p0) [打印本页]

作者: java 时间: 2017-7-28 10:52
标题: 数据库连性池性能测试(hikariCP,druid,tomcat-jdbc,dbcp,c3p0)

摘要: 本文主要是对这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

扩展性

弱

好

弱

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

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

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的开销。

欢迎光临 firemail (http://firemail.wang:8088/)