背景
對現有的資料庫連接配接池做調研對比,綜合性能,可靠性,穩定性,擴充性等因素選出推薦出最優的資料庫連接配接池 。
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的開銷。