近幾個(gè)月來，我們一直看到一小部分但持續(xù)的操作失敗，并帶有一個(gè)奇怪的異常– org.springframework.jdbc.CannotGetJdbcConnectionException –“無法獲得JDBC連接； 嵌套異常是java.sql.SQLException：客戶端嘗試檢出Connection的嘗試已超時(shí)。 ”

我們自然的假設(shè)是，我們的C3P0連接池存在某種爭用，試圖獲取連接的客戶端必須等待該爭用可用。 我們最好的猜測是正是這種爭用導(dǎo)致了超時(shí)。

因此，當(dāng)然，我們要做的第一件事是增加連接池中的最大連接數(shù)。 但是，無論我們將限制設(shè)置得多么高，它都無濟(jì)于事。 然后，我們嘗試更改連接的超時(shí)參數(shù)。 那沒有產(chǎn)生任何更好的結(jié)果。

此時(shí)，情報(bào)已經(jīng)確定下來，并且由于猜測似乎沒有用，因此我們決定進(jìn)行測量。 在連接池上使用一個(gè)簡單的包裝程序，我們看到即使連接池中有空閑連接，我們?nèi)匀粫?huì)得到簽出超時(shí)。

調(diào)查連接池開銷

為了研究連接池開銷，我們執(zhí)行了一個(gè)基準(zhǔn)測試，該基準(zhǔn)測試由6個(gè)回合組成，每個(gè)回合包括20,000個(gè)SQL操作（讀/寫比為1:10），使用20個(gè)線程和20個(gè)連接的連接池來執(zhí)行。 使用具有20個(gè)連接的池使用20個(gè)線程意味著資源（連接）上沒有爭用。 因此，任何開銷都是由連接池本身引起的。

我們忽略了第一次（預(yù)熱）運(yùn)行的結(jié)果，而取了隨后5次運(yùn)行的統(tǒng)計(jì)數(shù)據(jù)。 從這些數(shù)據(jù)中，我們收集連接簽出時(shí)間，連接釋放時(shí)間和總池開銷。

基準(zhǔn)項(xiàng)目代碼可以在以下位置找到： https : //github.com/yoavaa/connection-pool-benchmark

我們測試了3個(gè)不同的連接池：

• C3P0 – com.mchange：c3p0：0.9.5-pre3 – C3P0DataSourceBenchmark類
• Bone CP – com.jolbox：bonecp：0.8.0-rc1 –類BoneDataSourceBenchmark
• Apache DBCP – commons-dbcp：commons-dbcp：1.4 –類DbcpDataSourceBenchmark

（在該項(xiàng)目中，還有一個(gè)我自己的實(shí)驗(yàn)性異步池的基準(zhǔn)測試-https: //github.com/yoavaa/async-connection-pool 。但是，出于本文的目的，我將忽略它）。

為了自己運(yùn)行基準(zhǔn)測試，您應(yīng)該使用下表設(shè)置MySQL

CREATE TABLE item (file_name?? ? varchar(100) NOT NULL,user_guid?? ? varchar(50) NOT NULL,media_type ?? varchar(16) NOT NULL,date_created? datetime NOT NULL,date_updated? timestamp AUTO_INCREMENT NOT NULL DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY(file_name) )

然后更新Credentials對象以指向此MySQL安裝。

運(yùn)行基準(zhǔn)測試時(shí)，示例結(jié)果如下所示：

run, param, total time, errors, under 1000 nSec,1000 nSec - 3200 nSec,3200 nSec - 10 μSec,10 μSec - 32 μSec,32 μSec - 100 μSec,100 μSec - 320 μSec,320 μSec - 1000 μSec,1000 μSec - 3200 μSec,3200 μSec - 10 mSec,10 mSec - 32 mSec,32 mSec - 100 mSec,100 mSec - 320 mSec,320 mSec - 1000 mSec,1000 mSec - 3200 mSec,other 0, acquire,29587,0,0,5,1625,8132,738,660,1332,1787,2062,2048,1430,181,0,0,0 0, execution, , ,0,0,0,0,0,0,0,1848,6566,6456,5078,52,0,0,0 0, release, , ,0,8,6416,9848,3110,68,77,115,124,148,75,11,0,0,0 0, overhead, , ,0,0,49,4573,5459,711,1399,1812,2142,2157,1498,200,0,0,0 1, acquire,27941,0,0,125,8153,499,658,829,1588,2255,2470,2377,1013,33,0,0,0 1, execution, , ,0,0,0,0,0,0,6,1730,6105,6768,5368,23,0,0,0 1, release, , ,0,49,15722,3733,55,42,69,91,123,101,14,1,0,0,0 1, overhead, , ,0,0,2497,5819,869,830,1610,2303,2545,2448,1042,37,0,0,0

此信息已導(dǎo)入Excel文件（也包含在基準(zhǔn)項(xiàng)目中）以進(jìn)行分析。

C3P0

最初在C3P0中，我們在生產(chǎn)環(huán)境中看到了原始異常。 讓我們看看它如何執(zhí)行：

閱讀圖表：

前三個(gè)圖表（獲取，發(fā)布，開銷）是基于性能的存儲(chǔ)桶圖表。 Y軸表示在一定時(shí)間范圍內(nèi)完成的操作數(shù)（在X軸上顯示）。 默認(rèn)的經(jīng)驗(yàn)法則是，左側(cè)的條形越高，效果越好。 第4 ^個(gè)圖表是瀑布圖，其中每個(gè)水平線表示一個(gè)DB操作。 棕色表示等待獲取連接的時(shí)間，綠色表示執(zhí)行數(shù)據(jù)庫操作的時(shí)間，藍(lán)色表示將連接返回到連接池的時(shí)間。

從圖表中可以看出，通常，C3P0在3.2-10微秒內(nèi)獲得連接，并在3.2-10微秒內(nèi)釋放連接。 那絕對是一些令人印象深刻的表現(xiàn)。 但是，C3P0在約3.2-32毫秒處還有另一個(gè)峰值，而長尾巴則高達(dá)320-1000毫秒。 正是第二個(gè)高峰導(dǎo)致了我們的例外。

C3P0怎么了？ 是什么原因?qū)е铝诉@種極小但相當(dāng)大的超長操作百分比，而大多數(shù)時(shí)候卻表現(xiàn)驚人？ 縱觀4 ^個(gè)圖可以為我們指出了答案的方向。

第4 ^個(gè)圖表從左上角到右下角有一條清晰的對角線，表明總體上，連接獲取是按順序開始的。 但是我們可以識(shí)別出一些奇怪的東西–我們可以看到棕色的三角形，表示當(dāng)多個(gè)線程試圖獲取連接時(shí)，第一個(gè)線程比隨后的線程等待更多的時(shí)間。 這轉(zhuǎn)化為用于獲取連接的兩個(gè)性能“組”。 一些線程極其快速地獲得連接，而有些線程則餓死等待連接，而較后的線程的請求則得到了較早的答復(fù)。

早期線程比后續(xù)線程等待更長的時(shí)間的這種行為意味著不公平的同步。 事實(shí)上，挖掘到C3P0代碼時(shí)，我們已經(jīng)看到了收購的連接的過程中，C3P0使用“ 同步 ”關(guān)鍵字三次。 在Java中，“ synced ”關(guān)鍵字創(chuàng)建了不公平的鎖定，這可能導(dǎo)致線程饑餓。

稍后我們可能會(huì)嘗試使用公平鎖定來修補(bǔ)C3P0。 如果這樣做，我們自然會(huì)分享我們的發(fā)現(xiàn)。

此基準(zhǔn)測試的C3P0配置：

• 最小泳池大小：20
• 初始池大小：20
• 泳池最大大小：20
• 采集增量：10
• 輔助線程數(shù)：6

骨CP

我們在Wix上嘗試了BoneCP，但結(jié)果卻不盡相同，因此目前尚不確定我們是否喜歡它。 盡管分析并不全面，但我們將BoneCP基準(zhǔn)測試的結(jié)果包括在這些帖子中。

查看圖表，我們可以看到Bone的連接捕獲性能非常出色–大多數(shù)操作在3.2微秒內(nèi)完成，比C3P0快得多。 但是，我們還觀察到連接釋放時(shí)間很長，大約1-10毫秒，太高了。 我們還觀察到Bone的操作很長，開銷高達(dá)320毫秒。

從數(shù)據(jù)來看，在正常情況和“極端”情況下，BoneCP似乎都比C3P0好。 但是，如圖表所示，差異并不大。 查看第4 ^個(gè)圖表，我們看到與C3P0相比，棕色更少（因?yàn)檫B接獲取更好），但出現(xiàn)了藍(lán)線，表明線程等待連接釋放的時(shí)間。

如上所述，由于我們對使用BoneCP充其量是矛盾的，因此我們沒有投入大量資源來分析此連接池的性能問題。

Apache DBCP

Apache DBCP被稱為古老的數(shù)據(jù)源。 讓我們來看看與其他兩個(gè)相比的情況。

顯而易見的是-DBCP性能優(yōu)于C3P0和Bone。 在所有方面，無論是在連接檢查時(shí)間，連接釋放時(shí)間還是瀑布圖形式方面，它都優(yōu)于其他方法。

那么您應(yīng)該使用什么數(shù)據(jù)源？

好吧，這是一個(gè)不平凡的問題。 顯然，就連接池性能而言，我們顯然是贏家– DBCP。 似乎C3P0應(yīng)該很容易修復(fù)，我們可以嘗試一下。

但是，請務(wù)必記住，此調(diào)查的范圍僅限于實(shí)際連接獲取/釋放的性能。 實(shí)際的數(shù)據(jù)源選擇是一個(gè)更復(fù)雜的問題。 例如，該基準(zhǔn)測試忽略了一些重要方面，例如池的增長和縮小，網(wǎng)絡(luò)錯(cuò)誤的處理，數(shù)據(jù)庫故障時(shí)的故障轉(zhuǎn)移等等。

參考： 填充一個(gè)池需要多少個(gè)線程？ 來自我們的JCG合作伙伴 Yoav Abrahami，來自Wix IO博客。

翻譯自: https://www.javacodegeeks.com/2013/06/how-many-threads-does-it-take-to-fill-a-pool.html

總結(jié)

以上是生活随笔為你收集整理的填充一个池需要多少个线程？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。