效能沒有什麼Best Practice, 反正能調整的就那些。 通常，一個程式的效能大概有70-80% 都跟程式怎麼寫的其實比較有關係。
最近我最疼愛的小貓Puji 因為膀胱結石開刀的時候過世了，心情很差請原諒我的口氣沒有很好，也沒有心情寫部落格。
=======================正文=======================
這個題目很多人叫我寫，可是這題目好大，這分明就是整死我咩～
所以我會分幾段慢慢寫。
先來看一下 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下，
至於可以觀察哪些數據呢，打開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是可以看見的。
當然，校能調校還是要觀察久一點的比較好，所以這時候拿JON來看一整個禮拜的connection pool 的設定是最棒的拉～。在CLI 上面的參數也大多都看得到。
最近我最疼愛的小貓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是可以看見的。
當然，校能調校還是要觀察久一點的比較好，所以這時候拿JON來看一整個禮拜的connection pool 的設定是最棒的拉～。在CLI 上面的參數也大多都看得到。
突然想到， 如果你發現datasource 的 use-ccm 是等於 true，記得關掉，因為它很消耗資源的。
以上。
Comments