基礎(chǔ)連接池配置
- initialPoolSize : 初始連接數(shù)(default 3)
- minPoolSize :最小連接數(shù)(default 3)
- maxPoolSize :最大連接數(shù)(default 15)
- maxIdleTime :最大閑置時(shí)間, 未使用的連接在被丟棄之前在連接池存活時(shí)間,單位為秒(default 0, 永久存活)
- acquireIncrement : 獲取連接數(shù)量, 連接不足時(shí),c3p0嘗試一次獲取新連接的個(gè)數(shù)(default 3)
連接池中的連接數(shù)量在min和max之間變化,當(dāng)用戶需要一個(gè)連接的時(shí)候,如果當(dāng)前沒(méi)有可用連接,并且連接池中連接數(shù)量未達(dá)到上限的時(shí)候,連接池會(huì)創(chuàng)建一個(gè)新的連接。
獲取連接十分消耗資源,所以請(qǐng)求量很大的時(shí)候,我們應(yīng)該提高每次新增連接的個(gè)數(shù)而不是每次只新加一個(gè)連接并且讓客戶端等待。acquireIncrement 決定了每次新增連接的個(gè)數(shù),當(dāng)然這個(gè)數(shù)量不會(huì)圖片maxPoolSize的上限。
連接池中的連接在以下情況會(huì)被釋放
- 連接池通過(guò)測(cè)試發(fā)現(xiàn)連接可以斷開(kāi)
- 連接池設(shè)置了最大閑置時(shí)間, 連接超過(guò)這個(gè)時(shí)間未使用
3.連接太老了...
管理連接池大小和連接生命周期
我們根據(jù)不同的需求在性能,占用空間以及可靠性之前做出權(quán)限。C3P0提供一系列參數(shù)來(lái)對(duì)"連接池在大量負(fù)載以后需要多久將連接數(shù)降至最低", "為了提高可靠性,是否主要替換連接池中的'老'連接" 等情景進(jìn)行控制。
- maxConnectionAge ：連接最大存活時(shí)間(default 0, 永久存活)
- maxIdleTime
- maxIdleTimeExcessConnections ：超過(guò)minPoolSize的線程最大閑置時(shí)間(default 0, 永久存活)
默認(rèn)情況下, 連接池中的連接不會(huì)過(guò)期。如果想讓連接可以過(guò)期,maxIdleTime 和/或maxConnectionAge 都可以使用。maxConnectionAge的區(qū)別是連接從創(chuàng)建開(kāi)始,最大的存活時(shí)間, 即使這個(gè)連接并不空閑。
在連接池從大量負(fù)載閑置下來(lái)以后，如果我們想快速清理不需要的連接，可以給maxIdleTimeExcessConnections 設(shè)置一個(gè)比maxIdleTime小很多的值，強(qiáng)制連接池快速將閑置連接回收。
對(duì)于這些timeout的設(shè)置的建議：“慢，慢，慢！”。連接池的概念本身就是獲取一次連接，然后使用很多很多,很多次。大部分?jǐn)?shù)據(jù)庫(kù)允許連接保持好幾個(gè)小時(shí)或以上。沒(méi)有必要在幾分鐘內(nèi)甚至更短時(shí)間回收連接。將maxConnectionAge 或者 maxIdleTime 設(shè)置為1800 (30分鐘)已經(jīng)是非常激進(jìn)的了。對(duì)于大部分?jǐn)?shù)據(jù)庫(kù)來(lái)說(shuō),幾個(gè)小時(shí)或許更合適。我們可以通過(guò)測(cè)試來(lái)保證連接的可靠性。唯一可能需要設(shè)置為幾分鐘或者更短時(shí)間的是maxIdleTimeExcessConnections。
配置連接測(cè)試
c3p0可以通過(guò)多種方式測(cè)試連接,以減少應(yīng)用遇到連接失效的可能性。連接池中的連接可能有多種原因?qū)е率? 一些JDBC驅(qū)動(dòng)特意設(shè)置timeout; 數(shù)據(jù)庫(kù)或者網(wǎng)絡(luò)有時(shí)候會(huì)掛掉;連接本身可能因?yàn)橘Y源泄露,驅(qū)動(dòng)bug或者其他原因失效。
c3p0有多種測(cè)試連接的方式
- automaticTestTable :c3p0會(huì)根據(jù)傳入的名字創(chuàng)建一個(gè)空的測(cè)試表,通過(guò)對(duì)這個(gè)表的query進(jìn)行連接測(cè)試。并且會(huì)忽略prefferredTestQuery(default: null)
-
connectionTesterClassName :ConnectionTester 或者QueryConnectionTester
的實(shí)現(xiàn)類(lèi), 用來(lái)進(jìn)行連接測(cè)試, 一般不推薦使用 ( Default: com.mchange.v2.c3p0.impl.DefaultConnectionTester
) - preferredTestQuery： 定義用來(lái)測(cè)試連接的query語(yǔ)句，一般不推薦使用
- idleConnectionTestPeriod ： c3p0會(huì)測(cè)試所有的閑置但是沒(méi)有checked-out的連接, 時(shí)間間隔為設(shè)置的值(default:0 不進(jìn)行測(cè)試)
- testConnectionOnCheckin： 如果設(shè)置為true,在每個(gè)連接checkin的時(shí)候異步驗(yàn)證連接是否有效(default:false)
- testConnectionOnCheckout： 如果設(shè)置為true,在每個(gè)連接checkout的時(shí)候驗(yàn)證連接是否有效(default:false)
idleConnectionTestPeriod, testConnectionOnCheckout和testConnectionOnCheckin 決定"何時(shí)"測(cè)試連接。automaticTestTable, connectionTesterClassName和 preferredTestQuery 決定"怎樣"測(cè)試連接。
如果使用JDBC4并且c3p0在0.9.5版本以上,建議放手讓driver進(jìn)行連接測(cè)試,c3p0會(huì)首先嘗試使用JDBC4引入的isValid()方法進(jìn)行測(cè)試,這個(gè)方法速度快并且可靠。
對(duì)于之前的版本c3p0默認(rèn)在連接關(guān)聯(lián)的DatabaseMetaData上使用getTables()方法,這個(gè)方法非常穩(wěn)定并且適用于不同的數(shù)據(jù)庫(kù),但是比正常的query慢很多,使用它做連接測(cè)試可能會(huì)嚴(yán)重影響連接池性能。
在老版本中提升連接測(cè)試性能的一個(gè)簡(jiǎn)單的辦法是使用preferredTestQuery 定義一個(gè)測(cè)試query。但是需要注意的是,如果在datasource初始化之前query的表不存在的話， preferredTestQuery 會(huì)出錯(cuò)導(dǎo)致測(cè)試失敗。根據(jù)數(shù)據(jù)庫(kù)或者driver的不同, 像select 1這種的測(cè)試語(yǔ)句可能(不)會(huì)提高效率。
如果自定義query效率不夠好,使用automaticTestTable, c3p0會(huì)根據(jù)傳入的名稱建立一個(gè)空表來(lái)測(cè)試連接。
進(jìn)行連接測(cè)試最可靠的時(shí)機(jī)在check-out, 但是這也最為耗時(shí)。大多數(shù)應(yīng)用應(yīng)該可以通過(guò)一起使用idleConnectionTestPeriod和testConnectionOnCheckin進(jìn)行可靠測(cè)試,這兩個(gè)都是異步的,帶來(lái)更好的性能。
對(duì)有些應(yīng)用來(lái)說(shuō), 性能比偶發(fā)的數(shù)據(jù)庫(kù)異常更為重要。c3p0默認(rèn)不進(jìn)行連接測(cè)試。設(shè)置一個(gè)相對(duì)長(zhǎng)的ideaConnectionTestPeriod, 并不在check-in/out測(cè)試則會(huì)帶來(lái)高效的性能。
連接測(cè)試建議
- 如果你確定driver 支持JDBC4 Connection.isValid()方法,并且使用c3p0-0.9.5以上版本, 不要設(shè)置preferredTestQuery。
如果driver不支持這個(gè)方法(或者你不確定), 并且數(shù)據(jù)庫(kù)是MySQL或者Postgres, 在preferredTestQuery中使用SELECT 1。
對(duì)于其他數(shù)據(jù)庫(kù),參照這里的一些建議。
2.開(kāi)始直接設(shè)置testConnectionOnCheckout=true, 保證程序運(yùn)行正確和穩(wěn)定。如果性能讓你滿意,那就可以保持這個(gè)設(shè)置了,這是最簡(jiǎn)單最可靠測(cè)試連接的方法。但是它確實(shí)有很大的性能開(kāi)銷(xiāo)(客戶端可以感知的到)。
3.如果想減少連接檢查帶來(lái)的性能開(kāi)銷(xiāo)：
a. 設(shè)置testConnectionOnCheckout為false
b. 設(shè)置testConnectionOnCheckin為true
c. 設(shè)置idleConnectionTestPeriod 為30(秒),啟動(dòng)程序進(jìn)行測(cè)試。這個(gè)是一個(gè)很穩(wěn)定的設(shè)置,每30秒所有的連接在check-in的時(shí)候都會(huì)進(jìn)行測(cè)試。程序應(yīng)該很少會(huì)碰到關(guān)閉或者陳舊的連接,并且連接池應(yīng)該可以從數(shù)據(jù)庫(kù)關(guān)閉和重啟后迅速恢復(fù)。但是一直這樣測(cè)試還是會(huì)有一些開(kāi)銷(xiāo)。
d.如果數(shù)據(jù)庫(kù)很少進(jìn)行重啟,那么可以考慮增大idleConnectionTestPeriod間隔,比如300,然后測(cè)試看看客戶端是否會(huì)遇到關(guān)閉的連接。如果沒(méi)有,那么定格在300或者可以試更大的數(shù)字。然后考慮將testConnectionOnCheckin設(shè)置回false來(lái)減少check-in檢查。反之,如果遇到關(guān)閉的連接,可以考慮減少idleConnectionTestPeriod的值，將testConnectionOnCheckin設(shè)置回true。
參數(shù)的設(shè)置取決于對(duì)性能和可靠性的權(quán)衡，具體的數(shù)字并不重要，這里沒(méi)有一個(gè)準(zhǔn)確的“最佳值”，而是需要進(jìn)行測(cè)試。
選取2 還是3 取決于客戶端在check connection out以后的工作量，如果客戶端經(jīng)常執(zhí)行復(fù)雜查詢或者操作，一個(gè)很快的連接檢查不會(huì)有助于整體性能的提升。但是如果客戶端check connection out以后的操作很簡(jiǎn)單，那么附加一個(gè)額外的檢查會(huì)明顯拖慢性能。
理論上看起來(lái)很美好，但是我們往往很難進(jìn)行權(quán)衡。推薦的做法是測(cè)試3，看看是否會(huì)提高性能，是否會(huì)遇到關(guān)閉的連接，在數(shù)據(jù)庫(kù)重啟的情況下是否能夠恢復(fù)，再做出決定。
但是一定要保證測(cè)試本身的性能，JDBC是否支持isValid， 或者我們是否有一個(gè)合適的preferredTestQuery
配置Statement池
c3p0實(shí)現(xiàn)了JDBC定義的PreparedStatement的池. 有些時(shí)候,使用statement池可以顯著提高應(yīng)用性能。但是有的時(shí)候statement池帶來(lái)的開(kāi)銷(xiāo)可能會(huì)輕微影響性能。是否使用,怎么配置取決于數(shù)據(jù)庫(kù)的解析,執(zhí)行計(jì)劃,和對(duì)query語(yǔ)句的優(yōu)化(對(duì)于prepared statement)。不同的數(shù)據(jù)庫(kù)和不同的JDBC驅(qū)動(dòng)在這方面表現(xiàn)迥異。將不使用statement池的性能作為基準(zhǔn)來(lái)測(cè)試它可以帶來(lái)的性能提升是一個(gè)不錯(cuò)的方法。
statement池對(duì)應(yīng)的參數(shù)有以下幾種:
maxStatements 是JDBC中用來(lái)控制statement池的標(biāo)準(zhǔn)參數(shù)。表示DataSource中最多可以緩存的PreparedStatement的數(shù)量。當(dāng)達(dá)到上限的時(shí)候，pool會(huì)移除LRU(最近最少使用的) statement。這聽(tīng)起來(lái)十分簡(jiǎn)單,但是細(xì)想是一個(gè)很奇怪的行為。因?yàn)楸痪彺娴膕tatements從概念上來(lái)說(shuō)分屬各自的連接，并不是全局資源。為了找到一個(gè)合適的maxStatements大小,不會(huì)"毀掉"被緩存的statements,我們需要考慮經(jīng)常使用的PreparedStatement的數(shù)量,并且需要乘以連接池中連接的數(shù)量(連接池很忙的話可能達(dá)到maxPoolSize)。
maxStatementsPerConnection是一個(gè)非標(biāo)準(zhǔn)的配置參數(shù), 但是看起來(lái)更合理一些。 它定義了每個(gè)connection允許的PreparedStatement的最大數(shù)量。我們可以將這個(gè)值設(shè)置的比我們應(yīng)用中的"常用statements"的數(shù)量稍微大一些。
上述任何一個(gè)參數(shù)如果大于0, statement池就會(huì)開(kāi)啟。這兩個(gè)設(shè)置是分別生效的,彼此不會(huì)影響。
如果statementCacheNumDeferredCloseThreads大于0, statement池會(huì)推遲物理關(guān)閉緩存的statements的時(shí)機(jī),直到它所在的connection不再被使用。在一些JDBC driver中(特別是Oracle), connection在使用的時(shí)候是不會(huì)關(guān)閉它擁有的statement的。這個(gè)參數(shù)默認(rèn)值是0，如果發(fā)現(xiàn)有和connection 關(guān)閉任務(wù)相關(guān)的"明顯的死鎖",我們可以嘗試設(shè)置一個(gè)正數(shù),絕大多數(shù)情況這個(gè)值應(yīng)該是1。如果需要多余1個(gè)線程來(lái)做statement銷(xiāo)毀的工作，那么 我們可能需要調(diào)大maxStatements或者maxStatementsPerConnection, 而不是調(diào)大statementCacheNumDeferredCloseThreads。
