背景

對(duì)現(xiàn)有的數(shù)據(jù)庫(kù)連接池做調(diào)研對(duì)比，綜合性能，可靠性，穩(wěn)定性，擴(kuò)展性等因素選出推薦出最優(yōu)的數(shù)據(jù)庫(kù)連接池?。 ? ??

NOTE: 本文所有測(cè)試均是MySQL庫(kù)

測(cè)試結(jié)論

? ?1：性能方面?hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免鎖競(jìng)爭(zhēng)。

? ?2：druid功能最為全面，sql攔截等功能，統(tǒng)計(jì)數(shù)據(jù)較為全面，具有良好的擴(kuò)展性。

? ?3：綜合性能，擴(kuò)展性等方面，可考慮使用druid或者h(yuǎn)ikariCP連接池。

? ?4：可開(kāi)啟prepareStatement緩存，對(duì)性能會(huì)有大概20%的提升。

功能對(duì)比

功能	dbcp	druid	c3p0	tomcat-jdbc	HikariCP
是否支持PSCache	是	是	是	否	否
監(jiān)控	jmx	jmx/log/http	jmx,log	jmx	jmx
擴(kuò)展性	弱	好	弱	弱	弱
sql攔截及解析	無(wú)	支持	無(wú)	無(wú)	無(wú)
代碼	簡(jiǎn)單	中等	復(fù)雜	簡(jiǎn)單	簡(jiǎn)單
更新時(shí)間	2015.8.6	2015.10.10	?2015.12.09	?	2015.12.3
特點(diǎn)	依賴于common-pool	阿里開(kāi)源，功能全面	歷史久遠(yuǎn)，代碼邏輯復(fù)雜，且不易維護(hù)	?	優(yōu)化力度大，功能簡(jiǎn)單，起源于boneCP
連接池管理	LinkedBlockingDeque	數(shù)組	?	FairBlockingQueue	threadlocal+CopyOnWriteArrayList

• ?由于boneCP被hikariCP替代，并且已經(jīng)不再更新，boneCP沒(méi)有進(jìn)行調(diào)研。
• proxool網(wǎng)上有評(píng)測(cè)說(shuō)在并發(fā)較高的情況下會(huì)出錯(cuò)，proxool便沒(méi)有進(jìn)行調(diào)研。
• ?druid的功能比較全面，且擴(kuò)展性較好，比較方便對(duì)jdbc接口進(jìn)行監(jiān)控跟蹤等。
• c3p0歷史悠久，代碼及其復(fù)雜，不利于維護(hù)。并且存在deadlock的潛在風(fēng)險(xiǎn)。

性能測(cè)試

環(huán)境配置：

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：獲取關(guān)閉連接性能測(cè)試

? ? ? ?測(cè)試說(shuō)明：

• 初始連接和最小連接均為5，最大連接為20。在borrow和return均不心跳檢測(cè)
• 其中打開(kāi)關(guān)閉次數(shù)為: 100w次
• 測(cè)試用例和mysql在同一臺(tái)機(jī)器上面，盡量避免io的影響
• 使用mock和連接mysql在不同線程并發(fā)下的響應(yīng)時(shí)間

? ? ?圖形：

?

?

? ?mock性能數(shù)據(jù) (單位: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性能數(shù)據(jù)?(單位: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

測(cè)試結(jié)果：

• mock和mysql連接性能表現(xiàn)差不多，主要是由于初始化的時(shí)候建立了連接后期不再建立連接，和使用mock連接邏輯一致。?
• 性能表現(xiàn)：hikariCP>druid>tomcat-jdbc>dbcp>c3p0。
• ?hikariCP 的性能及其優(yōu)異。hikariCP號(hào)稱java平臺(tái)最快的數(shù)據(jù)庫(kù)連接池。
• ?hikariCP在并發(fā)較高的情況下，性能基本上沒(méi)有下降。
• ?c3p0連接池的性能很差，不建議使用該數(shù)據(jù)庫(kù)連接池。
  
  

? ?hikariCP性能分析：

• hikariCP通過(guò)優(yōu)化(concurrentBag，fastStatementList )集合來(lái)提高并發(fā)的讀寫(xiě)效率。
• hikariCP使用threadlocal緩存連接及大量使用CAS的機(jī)制，最大限度的避免lock。單可能帶來(lái)cpu使用率的上升。
• 從字節(jié)碼的維度優(yōu)化代碼。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes ）讓方法盡量在35個(gè)字節(jié)碼一下，來(lái)提升jvm的處理效率。

?

2：查詢一條語(yǔ)句性能測(cè)試

? ? ?測(cè)試說(shuō)明：

• 初始連接和最小連接均為8，最大連接為8。在borrow和return均不心跳檢測(cè)
• 查詢的次數(shù)為10w次，查詢的語(yǔ)句為 1：打開(kāi)連接 2：執(zhí)行 ：select 1 3：關(guān)閉連接
• 測(cè)試用例和mysql在同一臺(tái)機(jī)器上面，盡量避免io的影響

圖形：

? ?

?測(cè)試數(shù)據(jù)：

?	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

?

測(cè)試結(jié)果：

• ? 在并發(fā)比較少的情況下，每個(gè)連接池的響應(yīng)時(shí)間差不多。是由于并發(fā)少，基本上沒(méi)有資源競(jìng)爭(zhēng)。
• ? 在并發(fā)較高的情況下，隨著并發(fā)的升高，hikariCP響應(yīng)時(shí)間基本上沒(méi)有變動(dòng)。
• ? c3p0隨著并發(fā)的提高，性能急劇下降。

?

3：pscache性能對(duì)比

? ?測(cè)試說(shuō)明：

• 通過(guò)druid進(jìn)行設(shè)置pscache和不設(shè)置pscache的性能對(duì)比
• 初始連接和最小連接均為8，最大連接為8。在borrow和return均不心跳檢測(cè)。并且執(zhí)行的并發(fā)數(shù)為8.
• 查詢10w次。查詢流程為：1：建立連接，2：循環(huán)查詢preparestatement語(yǔ)句 3：close連接
• 測(cè)試用例和mysql在同一臺(tái)機(jī)器上面，盡量避免io的影響

? ?測(cè)試數(shù)據(jù)：

cache	1,927
not cache	2,134

? 測(cè)試結(jié)果：

• 開(kāi)啟psCache緩存,性能大概有20%幅度的提升?？煽紤]開(kāi)啟pscache.

? 測(cè)試說(shuō)明：

• psCache是connection私有的，所以不存在線程競(jìng)爭(zhēng)的問(wèn)題，開(kāi)啟pscache不會(huì)存在競(jìng)爭(zhēng)的性能損耗。
• psCache的key為prepare執(zhí)行的sql和catalog等，value對(duì)應(yīng)的為prepareStatement對(duì)象。開(kāi)啟緩存主要是減少了解析sql的開(kāi)銷(xiāo)。

總結(jié)

以上是生活随笔為你收集整理的数据库连接池性能比对(hikari druid c3p0 dbcp jdbc)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。