DBCP,C3P0,Tomcat_JDBC 性能及穩定性測試

openkk 12年前發布 | 252K 次閱讀 C3P0 數據庫連接池

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）的時間，而是連接池“獲取連接然后馬上關閉連接”的時間。

測試結果：

</tr>

</tr> </tbody> </table>

DB POOL	線程數量	單線程執行次數	消耗時間 (ms)	開始時間 (ms)	結束時間 (ms)	平均消耗時間(ms)	平均單條時間(ms)
DBCP	10	1000	251	1328863445815.00	1328863446066.00	251	0.0251
			252	1328863466569.00	1328863466821.00
			251	1328863477174.00	1328863477425.00
			254	1328863487555.00	1328863487809.00
			247	1328863499474.00	1328863499721.00
C3P0	10	1000	781	1328863372064.00	1328863372845.00	802.8	0.08028
			789	1328863385489.00	1328863386278.00
			879	1328863401335.00	1328863402214.00
			773	1328863413608.00	1328863414381.00
			792	1328863424693.00	1328863425485.00
TomcatJDBC	10	1000	191	1328863272642.00	1328863272833.00	191.8	0.01918
			197	1328863303126.00	1328863303323.00
			187	1328863313262.00	1328863313449.00
			195	1328863324253.00	1328863324448.00
			189	1328863334700.00	1328863334889.00

</tr>

</tr> </tbody> </table>

DB POOL	線程數量	單線程執行次數	消耗時間 (ms)	開始時間 (ms)	結束時間 (ms)	平均消耗時間(ms)	平均單條時間(ms)
DBCP	100	1000	786	1328862922748.00	1328862923534.00	810.4	0.008104
			853	1328862939832.00	1328862940685.00
			810	1328862955354.00	1328862956164.00
			807	1328862981344.00	1328862982151.00
			796	1328862994825.00	1328862995621.00
C3P0	100	1000	2517	1328863021884.00	1328863024401.00	2248.8	0.022488
			2340	1328863040949.00	1328863043289.00
			1968	1328863075044.00	1328863077012.00
			2256	1328863092216.00	1328863094472.00
			2163	1328863114138.00	1328863116301.00
TomcatJDBC	100	1000	752	1328863155803.00	1328863156555.00	726	0.00726
			725	1328863171617.00	1328863172342.00
			694	1328863183983.00	1328863184677.00
			703	1328863195628.00	1328863196331.00
			756	1328863209798.00	1328863210554.00

</tr>

</tr> </tbody> </table>

DB POOL	線程數量	單線程執行次數	消耗時間 (ms)	開始時間 (ms)	結束時間 (ms)	平均消耗時間(ms)	平均單條時間(ms)
DBCP	150	1000	1919	1328861533609.00	1328861535528.00	1854.4	0.012363
			1957	1328861551638.00	1328861553595.00
			1869	1328861746964.00	1328861748833.00
			1916	1328861791533.00	1328861793449.00
			1611	1328861832003.00	1328861833614.00
C3P0	150	1000	2726	1328861869415.00	1328861872141.00	2990.8	0.019939
			2570	1328861895349.00	1328861897919.00
			3342	1328861912351.00	1328861915693.00
			3218	1328861929664.00	1328861932882.00
			3098	1328861950163.00	1328861953261.00
TomcatJDBC	150	1000	877	1328861974599.00	1328861975476.00	861	0.00574
			821	1328861990969.00	1328861991790.00
			890	1328862016507.00	1328862017397.00
			857	1328862037077.00	1328862037934.00
			860	1328862052490.00	1328862053350.00

</tr>

</tr> </tbody> </table>

結論：

總體性能：TomcatJDBC > DBCP > C3P0

網上好多資料都說C3P0的性能要好于DBCP,從我的測試結果來看并不是這樣，也許是我的配置有不正確的地方，

測試時最大的活動線程配置為100，并發為150線程時，TomcatJDBC的優勢明顯，

也就是當并發超過連接池最大的活動線程數，但并沒有超過太多的情況下，TomcatJDBC的優勢明顯，

我測試的結果都是毫秒級，

對于一個小型的系統，并發壓力不大時，選擇哪個連接池都沒有太大差別，考慮更多的應該是連接池的穩定性。

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性能要求較高時，可以不進行驗證。

轉自：http://aub.iteye.com/blog/1404219

本文由用戶 openkk 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1329182303124.html

C3P0 數據庫連接池

DB POOL	線程數量	單線程執行次數	消耗時間 (ms)	開始時間 (ms)	結束時間 (ms)	平均消耗時間(ms)	平均單條時間(ms)
DBCP	300	1000	3908	1328862516139.00	1328862520047.00	3851.8	0.012839
			3850	1328862408362.00	1328862412212.00
			3939	1328862440877.00	1328862444816.00
			3806	1328862469116.00	1328862472922.00
			3756	1328862495883.00	1328862499639.00
C3P0	300	1000	6111	1328862711585.00	1328862717696.00	6233.2	0.020777
			5162	1328862618669.00	1328862623831.00
			6261	1328862638870.00	1328862645131.00
			6832	1328862659598.00	1328862666430.00
			6800	1328862681808.00	1328862688608.00
TomcatJDBC	300	1000	3458	1328862152316.00	1328862155774.00	3403.8	0.011346
			3376	1328862308211.00	1328862311587.00
			3397	1328862227685.00	1328862231082.00
			3342	1328862261681.00	1328862265023.00
			3446	1328862358400.00	1328862361846.00

DBCP,C3P0,Tomcat_JDBC 性能及穩定性測試

相關經驗

相關資訊

相關文檔

目錄