數據庫鏈接池性能測試(hikariCP,druid,tomcat-jdbc,dbcp,c3p0)

本文主要是對這hikariCP,druid,tomcat-jdbc,dbcp,c3p0幾種鏈接池的詳細的功能和性能測試對比,經過此次測試對目前主流的一些鏈接池作一個全面的對比，從而給業務系統一個最佳的推薦。

測試結論

1. 性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益於最大限度的避免鎖競爭。
2. druid功能最爲全面，sql攔截等功能，統計數據較爲全面，具備良好的擴展性。
3. 綜合考慮到目前venus已經支持druid且hikariCP並未發現有太多大規模的生產實踐的案例，後續將推薦使用druid並把codegen生成的代碼默認鏈接池爲druid。
4. 可開啓prepareStatement緩存，對性能會有大概10%的提高。

功能對比

功能	dbcp	druid	c3p0	tomcat-jdbc	HikariCP
是否支持PSCache	是	是	是	否	否
監控	jmx	jmx/log/http	jmx,log	jmx	jmx
擴展性	弱	好	弱	弱	弱
sql攔截及解析	無	支持	無	無	無
代碼	簡單	中等	複雜	簡單	簡單
更新時間	2018.1.13	2018.1.14	2017.5.4		2018.1.14
特色	依賴於common-pool	阿里開源，功能全面	歷史久遠，代碼邏輯複雜，且不易維護		優化力度大，功能簡單，起源於boneCP
鏈接池管理	LinkedBlockingDeque	數組		FairBlockingQueue	threadlocal+CopyOnWriteArrayList
線程	1個線程(心跳)	2個線程	4個		3個

線程的做用

1. dbcp：一個線程：負責心跳，最小鏈接數維持，最大空閒時間和防鏈接泄露。
2. druid: 兩個線程： 其中一個負責異步建立。一個負責最小鏈接數的維持。 其中心跳是經過獲取鏈接，來斷定是否小於心跳間隔。
3. hikariCP: 三個線程： 其中一個爲定時線程，解決最大空閒時間。兩個爲新建鏈接和關閉鏈接。 均是鏈接池，空閒5s，線程便會關閉。
4. 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的開銷。