天天看點

資料庫連接配接池性能比對背景 測試結論 功能對比 性能測試

背景

對現有的資料庫連接配接池做調研對比,綜合性能,可靠性,穩定性,擴充性等因素選出推薦出最優的資料庫連接配接池 。     

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