数据库连接池性能比对

标签: 数据库 性能 比对 | 发表时间:2016-01-06 10:59 | 作者:hetaohappyqqqq
出处:http://www.iteye.com

背景

对现有的数据库连接池做调研对比,综合性能,可靠性,稳定性,扩展性等因素选出推荐出最优的数据库连接池 。     

NOTE: 本文所有测试均是mysql库

测试结论

   1:性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免锁竞争。

   2:druid功能最为全面,sql拦截等功能,统计数据较为全面,具有良好的扩展性。

   3:综合性能,扩展性等方面,可考虑使用druid或者hikariCP连接池。

   4:可开启prepareStatement缓存,对性能会有大概20%的提升。

功能对比

功能 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
  •  由于boneCP被hikariCP替代,并且已经不再更新,boneCP没有进行调研。
  • proxool网上有评测说在并发较高的情况下会出错,proxool便没有进行调研。
  •  druid的功能比较全面,且扩展性较好,比较方便对jdbc接口进行监控跟踪等。
  • c3p0历史悠久,代码及其复杂,不利于维护。并且存在deadlock的潜在风险。

性能测试

环境配置:

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

 

1:获取关闭连接性能测试

       测试说明:

  • 初始连接和最小连接均为5,最大连接为20。在borrow和return均不心跳检测
  • 其中打开关闭次数为: 100w次
  • 测试用例和mysql在同一台机器上面,尽量避免io的影响
  • 使用mock和连接mysql在不同线程并发下的响应时间

     图形:

 

 

   mock性能数据 (单位:ms)

  5 20 50 100
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)

  5 20 50 100
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的处理效率。

 

2:查询一条语句性能测试

     测试说明:

  • 初始连接和最小连接均为8,最大连接为8。在borrow和return均不心跳检测
  • 查询的次数为10w次,查询的语句为 1:打开连接 2:执行 :select 1 3:关闭连接
  • 测试用例和mysql在同一台机器上面,尽量避免io的影响

图形:

   

 测试数据:

  5 8 20 50 100
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随着并发的提高,性能急剧下降。

 

3: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缓存,性能大概有20%幅度的提升。可考虑开启pscache.

  测试说明:

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


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [数据库 性能 比对] 推荐:

数据库连接池性能比对

- - 企业架构 - ITeye博客
对现有的数据库连接池做调研对比,综合性能,可靠性,稳定性,扩展性等因素选出推荐出最优的数据库连接池 . NOTE: 本文所有测试均是mysql库.    1:性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0. hikariCP的高性能得益于最大限度的避免锁竞争.    2:druid功能最为全面,sql拦截等功能,统计数据较为全面,具有良好的扩展性.

DB2数据库性能优化介绍

- - CSDN博客数据库推荐文章
作者:chszs,转载需注明. 博客主页: http://blog.csdn.net/chszs. 前段时间,我从CSDN得到了这本书《DB2数据库性能调整和优化(第2版)》,这是一本介绍DB2数据库性能调优的书籍,此书覆盖了DB2数据库性能调优所需的全部知识和工具,而且还提供了大量的性能调优的实际案例,颇有一种“一书在手,DB2尽在掌握”的豪情.

浅谈MySQL 数据库性能优化

- - BlogJava-qileilove
数据库是 IO 密集型的程序,和其他数据库一样,主要功能就是数据的持久化以及数据的管理. 本文侧重通过优化MySQL 数据库缓存参数如查询缓存,表缓存,. 日志缓存,索引缓存,innodb缓存,插入缓存,以及连接参数等方式来对MySQL数据库进行优化.   这里先引用一句话,从内存中读取一个数据的时间消耗是微秒级别,而从普通硬盘上读取一个数据是在毫秒级别,二者相差3个数量级.

基于SSD的数据库性能优化

- Sungelina - Hello DBA
NOR和NAND都是闪存技术的一种,NOR是Intel公司开发的,它有点类似于内存,允许通过地址直接访问任何一个内存单元,缺点是:密度低(容量小),写入和擦除的速度很慢. NAND是东芝公司开发的,它密度高(容量大),写入和擦除的速度都很快,但是必须通过特定的IO接口经过地址转换之后才可以访问,有些类似于磁盘.

MySQL 数据库性能优化之表结构

- tangfl - Sky.Jian 朝阳的天空
接着上一篇 MySQL 数据库性能优化之缓存参数优化 ,这是 MySQL数据库性能优化专题 系列的第二篇文章:MySQL 数据库性能优化之表结构. 很多人都将 数据库设计范式 作为数据库表结构设计“圣经”,认为只要按照这个范式需求设计,就能让设计出来的表结构足够优化,既能保证性能优异同时还能满足扩展性要求.

MySQL 数据库性能优化之缓存参数优化

- flychen50 - Sky.Jian 朝阳的天空
在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题,所以最近打算写一个MySQL数据库性能优化方面的系列文章,希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助. 这是 MySQL数据库性能优化专题 系列的第一篇文章:MySQL 数据库性能优化之缓存参数优化.

MySQL数据库性能优化之存储引擎选择

- - Sky.Jian 朝阳的天空
MySQL 数据库性能优化之SQL优化,这是  MySQL数据库性能优化专题 系列的第五篇文章:. MySQL数据库性能优化之存储引擎选择. 离上一篇文章已经有很长时间没有更新这个MySQL数据库性能优化专题了,时间太紧加上人之惰性,今天这里将之前就规划好的关于存储引擎选择方面的内容更新出来,希望对大家有所帮助吧.

高性能key-value数据库nessDB介绍

- - NoSQLFan
nessDB是一个小巧、高性能、可嵌入式的key/value存储引擎,使用标准C开发,支持Linux, *BSD, OS X and Solaris等系统,无第三方库依赖. 本文来自nessDB作者@ BohuTANG 的投稿分享,推荐给大家. 同时nessDB还提供一个服务端,支持Redis的 PING, SET, MSET, GET, MGET, DEL, EXISTS, INFO, SHUTDOWN 命令,您可以使用任何一款Redis客户端来连接和操作nessDB.

MySQL数据库性能优化之硬件瓶颈分析

- - Sky.Jian 朝阳的天空
接着上一篇 MySQL数据库性能优化之存储引擎选择,这是 MySQL数据库性能优化专题 系列的第六篇文章: MySQL数据库性能优化之硬件优化. 在过往与很多人的交流过程中发现,在谈到基于硬件来进行数据库性能瓶颈分析的时候,常被大家误解为简单的使用更为强劲的主机或者存储来替换现有的设备. 个人觉得这其中可能存在一个非常大的误区.

谈数据库容量和性能测算

- - 人月神话的BLOG
原来我们谈到过IT系统建设的业务模型TPMC估算,这里主要针对数据库服务器谈数据库容量和性能估算,该篇文章内容部分来自IBM网站一篇数据库容量性能规划的文章,地址现状不详. 总体来说数据库容量核心分析对象还是数据库表,配合数据库表的包括了视图,索引,日志等相关附属信息. 这些信息汇总后考虑3-5年的数据库容量增长情况给出数据库最终容量估算情况.