JBoss EAP 6 - 效能調校 (一) DataSource 的 Connection Pool

效能沒有什麼Best Practice, 反正能調整的就那些。通常，一個程式的效能大概有70-80% 都跟程式怎麼寫的其實比較有關係。

最近我最疼愛的小貓Puji 因為膀胱結石開刀的時候過世了，心情很差請原諒我的口氣沒有很好，也沒有心情寫部落格。

Puji R.I.P.

=======================正文=======================

這個題目很多人叫我寫，可是這題目好大，這分明就是整死我咩～
所以我會分幾段慢慢寫。

JBoss 的 Subsystem

Datasource
Web
Web Service
EJB
Hibernate
JMS
JCA

JVM 調校
OS (作業系統)

先來看一下 DataSource Subsystem, DataSource 的部分主要是針對Connection Pool 做調校。

通常，程式都會需要跟資料庫界接，電腦在本機，尤其是在記憶體的運算很快，但是一旦要外部的資源連接，就是會非常的耗資源。所以現在的應用程式伺服器都會有個Pool 放一些先連接好的資料庫connection,當程式有需要的時候就可以馬上提供，而不用花那些多餘的資源去連接資料庫。

這就是為什麼要針對Connection Pool 去做調校。

以下會討論到的參數，都是跟效能比較有關係，Datasource 還有很多參數，像是檢核connection 是否正確的，我都不會提到。如果你追求的是非常快速的效能，那我建議你一個檢核都不要加。當然，這樣就會為伺服器上面執行的程式帶來風險。這就是你要在效能與正確，安全性上面的取捨了。 (套句我朋友說的話，不可能又要馬兒好，又要馬兒不吃草的..)

最重要的調校參數就是 Connection 的 Pool 數量。(也就是那個Pool 裡面要放幾條的connection.) 這個參數是每一個應用程式都不一樣的。

min-pool-size

Connection Pool 最少會存留的connection 數量

max-pool-size

Connection Pool 最多可以開啓的 connection 數量

prefill

事先將connection pool 裡面建立好min-pool-size 的connection.

我的建議是觀察一下平常程式要用到的量設定為 min-pool-size 。
加上可能會衝高的最大量以及確認測試過資料庫可以承受的數量 max-pool-size 再 x 20%~30 %以上。不用擔心設的太大，反正你沒用到那麼多，connection pool 也不會真的建這麼多。

還有一個prefill 的參數，我建議是把它打開，這個參數會在JBoss EAP 一起動的時候，把connection pool 裡面的connection 先建立到connection pool 裡面。這樣就可以減少一開始程式要連接到資料庫要消耗的時間以及資源。

還有一個比較重要的參數，就是 timeout 的參數。

blocking-timeout-millis

這個參數是指，當你的connection pool 裡面所有的connection 都被現在跑的程式拿光光的時候，下一個程式在那裡排隊等待下一個可用connection 的時間。超過時間就會出exception 了。(PS, 這只是等待拿到connection的時間喔～如果你很快就拿到一個connection, 可是建立的時候可能因為資料庫出問題，所以等了很久，這段的時間是不算的喔。) 預設的時間是 30秒。

idle-timeout-minutes

Connection Pool 裡面的connection 發呆很久沒人用的等待時間，如果超過這個時間 (分鐘計算喔) 都沒人來用它的話～那就把這個connection 關掉。它的底層就是一個叫做 idleRemover 的thread, 大概隔一段時間就會起來scan 看看 connection time 超過idle-timeout的，如果有就關閉。所以connection 並不是一到時間就會馬上自動關閉，要等到 idleRemover scan 時才會真的關掉。而 idleRemover 大概就是你所有 pool 的設定最小的 idle-timeout-minutes 一半的時間。

set-tx-query-timeout

是否要設定查詢的timeout 時間，當然還是以整個交易timeout 為主。如果你的query timeout 時間還沒到，整個transaction(交易) 就 timeout 的話，還是以transaction(交易)第一優先。

query-timeout

這個參數需要上一個 set-tx-query-timeout 設定成true 才會有作用，不然default 就是0 不會timeout. 這個參數是查詢一次要多久的時間，超過的timeout.

如果你不想要太多卡在伺服器上面的交易的話，請盡量把上面的timeout時間設短，當然，相對的程式就會出現很多timeout 的exception, 以正常來說，timeout 的時間不可過長，交易一定要比timeout使用的時間更短，如果很長的話，可能要看一下資料庫的狀態，程式寫的方式，甚至是資源根本就是不夠用。

設定的地方就在 datasource的這個subsystem下，


    
        jdbc:mysql://localhost:5432/MyDB
    
    mysql
    
        10
        30
        true
    
    
        30000
        5
        true
        30

至於可以觀察哪些數據呢，打開CLI 來看看：

[standalone@localhost:9999 statistics=pool] :read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"ActiveCount" => "0",
"AvailableCount" => "20",
"AverageBlockingTime" => "0",
"AverageCreationTime" => "0",
"CreatedCount" => "0",
"DestroyedCount" => "0",
"InUseCount" => "0",
"MaxCreationTime" => "0",
"MaxUsedCount" => "0",
"MaxWaitCount" => "0",
"MaxWaitTime" => "0",
"TimedOut" => "0",
"TotalBlockingTime" => "0",
"TotalCreationTime" => "0"
}
}

主要看一下 ActiveCount, 看看目前總共有多少活著的connection, AvailableCount 看一下pool裡面是都滿了，還是Connection 大部份都借出去了. MaxUseCount 可以拿來看系統最大最巔峰的時候，開了多少的connection 出去用。 MaxCreationTime 告訴你，建立一個connection 最久花多久。如果很久的話，要查查看資料庫的資源是否夠，或是網路有問題。如果MaxWaitCount 太高的話，可能是connection pool 太小，或是有connection leak造成要一個connection排隊排太長了等等...

或是你可以在 Console 上面看l，雖然沒有很多參數，但最主要的pool size是可以看見的。