數據庫連接池性能比對(hikari druid c3p0 dbcp jdbc)

https://blog.csdn.net/qq_31125793/article/details/51241943

背景

對現有的數據庫連接池做調研對比，綜合性能，可靠性，穩定性，擴展性等因素選出推薦出最優的數據庫連接池 。     

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的開銷。