DBCP,C3P0,Tomcat_JDBC 性能及穩定性測試
1.測試環境：
硬件環境：
數據庫服務器：2U*8核 8G內存
測試服務器： 2U*8核 6G內存
軟件環境：
jdk：
1.6.29
mysql：
5.0.77
mysql_driver：
mysql-connector-java-5.0.8-bin.jar
DBCP：
commons-dbcp-1.4.jar
下載地址： http://commons.apache.org/dbcp/
commons-pool-1.5.6.jar
下載地址： http://commons.apache.org/pool/
C3P0：
c3p0-0.9.1.2.jar
下載地址： http://www.mchange.com/projects/c3p0/index.html
log4j-1.2.8.jar（c3p0需要添加此包）
下載地址： http://logging.apache.org/log4j/
Tomcat_JDBC：
tomcat-jdbc.jar
下載地址： https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
或者在tomcat安裝根目錄下的lib目錄中直接拿來用之
tomcat-juli.jar
下載地址：（沒找到）
在tomcat安裝根目錄下的bin目錄中直接拿來用之
配置信息：
數據庫連接超時時間設置爲： 10年
數據庫支持最大連接數設置爲：2000
初始化連接池大小：10
連接至最小活動線程數：10
連接池最大活動線程數：100
其他配置均保持各個連接池的默認配置
2.性能測試： （測試代碼見附件）
測試點：
在多線程多任務的條件下，各個連接池獲取連接然後馬上關閉連接，比較所消耗的時間。
在網上看了好多關於數據庫連接池方面的測試，
大多數測試過程中，包括了執行sql語句部分，即，創建連接，執行sql語句，關閉連接，
一開始我也是這樣測試，
測試過過程中，發現數據很不穩定， 這幾個連接池都是忽快忽慢，
經過思考、分析，個人 覺得這樣是不準確的，執行sql語句時，測試已經不是數據庫連接池的性能了，
完全是數據庫驅動程序（例如mysql_driver ）和數據庫本身的性能，
數據庫連接池負責的僅僅是建立DataSource，獲取（從連接池中獲取）Connection，關閉（放回到連接池）Connection，
因此，
我在測試時，沒有計算初始化連接池（建立DataSource）的時間，而是連接池“獲取連接然後馬上關閉連接”的時間。
測試結果：
平均消耗時間是每個用例測試了5次計算出來的
| DB POOL | 線程數量 | 單線程 執行次數 |
平均消耗 時間(ms) |
平均單條 時間(ms) |
| DBCP | 10 | 1000 | 251 | 0.0251 |
| C3P0 | 10 | 1000 | 802.8 | 0.08028 |
| TomcatJDBC | 10 | 1000 | 191.8 | 0.01918 |
| DB POOL | 線程數量 | 單線程 執行次數 |
平均消耗 時間(ms) |
平均單條 時間(ms) |
| DBCP | 100 | 1000 | 810.4 | 0.008104 |
| C3P0 | 100 | 1000 | 2248.8 | 0.022488 |
| TomcatJDBC | 100 | 1000 | 726 | 0.00726 |
| DB POOL | 線程數量 | 單線程 執行次數 |
平均消耗 時間(ms) |
平均單條 時間(ms) |
| DBCP | 150 | 1000 | 1854.4 | 0.012363 |
| C3P0 | 150 | 1000 | 2990.8 | 0.019939 |
| TomcatJDBC | 150 | 1000 | 861 | 0.00574 |
| DB POOL | 線程數量 | 單線程 執行次數 |
平均消耗 時間(ms) |
平均單條 時間(ms) |
| DBCP | 300 | 1000 | 3851.8 | 0.012839 |
| C3P0 | 300 | 1000 | 6233.2 | 0.020777 |
| TomcatJDBC | 300 | 1000 | 3403.8 | 0.011346 |
結論：
總體性能：TomcatJDBC > DBCP > C3P0
網上好多資料都說C3P0的性能要好於DBCP,從我的測試結果來看並不是這樣，也許是我的配置有不正確的地方，
測試時最大的活動線程配置爲100，
併發爲150線程時，TomcatJDBC的優勢明顯，
也就是當併發超過連接池最大的活動線程數，但並沒有超過太多的情況下，TomcatJDBC的優勢明顯，
當併發數爲300時，3種連接池性能差距不大，
出現這種情況，說明連接池的最大活動線程數已經不滿足現有系統需求，需要調整配置了
我測試的結果都是毫秒級，
對於一個小型的系統，併發壓力不大時，選擇哪個連接池都沒有太大差別，考慮更多的應該是連接池的穩定性。
3.穩定性測試： （測試代碼見附件）
測試點：
1.當數據庫由於未知原因關閉，重新啓動後，連接池是否可以自動重連，無需重啓應用服務。
2.應用服務正常，數據庫服務正常，但是網絡環境異常，導致連接中斷，此時連接池中連接處於“半連接”狀態，
現象：
在不重啓應用服務的情況下， mysql數據庫進行重啓操作，mysql完全重啓後，執行程序，
TomcatJDBC和DBCP並沒有自動重連，重複執行查詢語句，會一直報異常，重啓應用服務後恢復正常
C3P0進行了自動重連，重複執行查詢語句，執行正常。
結論：
默認配置條件下，TomcatJDBC和DBCP並沒有自動重連機制，查看官方文檔，這缺陷可以通過修改配置解決。
另：
連接池重連機制，有2種：
1.同步驗證方式：
每次獲取連接或關閉連接時，執行一個預定義的驗證語句（sql語句），
驗證連接池中的連接是否有效，如果驗證失敗，徹底關閉此連接，
這種方式會導致每次執行數據庫操作時都有額外的開銷，對性能影響較大。
2.心跳驗證方式：
每隔特定的時間進行一次驗證，執行一個預定義的驗證語句（sql語句），
驗證連接池中的連接是否有效，如果驗證失敗，徹底關閉此連接，
可以根據具體情況，適當的調節驗證間隔時間。
這種方式以犧牲較小的性能開銷爲代價，來保持系統的穩定性。
4.心得
自從tomcat7發佈以來，網絡上開始出現一個新的連接池的影子，tomcat jdbc,
經過測試，發現tomcat jdbc的性能果然不錯，是連接池不二的選擇，
本人E文水平有限，沒辦法把E文翻譯的那麼優雅，
tomcat jdbc的其他優點，還請看它的官網介紹
https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
這篇文章詳細介紹闡述dbcp與c3p0的一些不足：
Why another connection pool project
重連機制：
不推薦使用同步驗證方式，
如果系統架構中，網絡環境（應用服務與數據庫服務之間）不穩定，硬件環境不穩定，推薦使用心跳驗證方式。
如果系統架構中，網絡環境和硬件環境都機器穩定，而且對數據庫I/O性能要求較高時，可以不進行驗證。
5.測試代碼見附件：
類：TestPerformance，性能測試
類：TestStability，穩定性測試，定時執行查詢語句，
類：TestWacthPool，自動重連測試，簡單觀察連接池內部狀態
如有有疑問可以加我QQ: 35443224 請說明您是51cto技術博客的朋友， ^_^