IBM WebSphere Application Server （以下簡稱 WAS）能支持的應用程序越來越多，而這些應用程序有各自的獨特特性、需求和服務。正如任何兩個應用程序都不會採用完全相同的方式來使用應用服務器一樣， 我們也無法通過一組調優參數來爲任意兩種不同的應用程序提供最佳性能。本篇文章將重點放在 WebSphere 服務器中各種池資源的調優上，重點向讀者介紹線程池、連接池和 ORB 的作用以及調優的基本準則，通過本篇文章，讀者會對 WAS 調優有更加精確的掌握，特別是對各種池資源配置的瞭解會更加深入。從而能使自己更加有效率的使用 WebSphere 服務器。
免費下載：IBM® WebSphere® Application Server 試用版
是什麼引起了性能問題？或者如何提高系統的性能？這是我們在系統的開發和維護時經常會碰到的問題，但是這兩個問題很難回答。正如下圖所示，性 能問題可能發生於系統的各個環節中，當性能問題出來後很難馬上就定位性能的瓶頸在哪裏，即使找到了性能瓶頸，在進行調優的時候也要考慮系統整體環境，從上 下文中分析，確定調優的策略；系統中一個或者多個“短板”的存在，就能讓系統無法達到設計時的目標，無法達到預期的性能提升。
在本文中，我們將重點放在 WebSphere 中各種池資源的調優上，包括線程池、數據庫連接池以及 ORB 的連接數調優。池（Pool）是 WebSphere 中最常涉及的概念之一。從網絡、Web 服務器、Web 容器、EJB 容器，一直到數據源，每一個環節都有線程池、連接池的影子。這些池資源從上到下被連接在一起，就形成了一個訪問和應答的隊列。在 WebSphere 的調優中，如果能合理的配置這些池資源，可以從很大程度上提高整個系統的運行效率。
圖 1. 性能問題發生在 WAS 和操作系統的各個中
系統性能差一般有以下兩種非常明顯的表現形式，第一種是 CPU 使用不高，用戶感覺交易響應時間很長；第二種是 CPU 使用很高，用戶感覺交易響應時間很長。對於第一種情況，可以斷定是由於系統的某一小部分造成了瓶頸，導致了所有的請求都在等待。簡單舉例來說，線程池的數 量開的太小，導致所有的請求都在排隊等待進入線程池，因爲沒有可用的線程使用，所以這個交易請求一直在排隊，導致交易響應時間很長。如果數據庫連接池開的 太小，也會有同樣的表現。對於第二種情況，比較複雜。可能的根源之一是硬件資源不夠。根源之二是應用系統中產生了多個大對象。根源之三是程序算法有問題。 解決思路如下： 用性能分析器，如 RAD 或 JProfiler, 對運行環境進行分析，分析哪個類甚至於哪個函數消耗了這麼多的 CPU，並找到相應的解決方案。
WAS 性能調優沒有捷徑和魔術，因爲每一個應用都有自己獨特的特性和資源需求，而且他們使用 WAS 的資源也有各種不同的方式，每一套調優的參數和策略僅適用於當前的系統環境，在實際的系統環境中不能簡單的將一種調優策略原封不動的移植到另外一個系統環 境中，這樣往往得不到預期的調優目的，還可能照成更多的性能瓶頸。
WAS 是由一系列相互作用的組件連接而成的，必須對這些被連接在一起的組件進行合理的調優，才能夠滿足客戶的應用對系統性能的要求。這些調整和調優將幫助系統達到最大的吞吐率和最高的使用效率。
當客戶端發出一個請求時，該請求會從網絡端開始依次進入 WehSphere 服務器的各個組件，這些請求會在各個組件中進行排隊等候使用服務器資源或者等待進入下一個組件進一步被服務器處理請求，每個組件裏的請求組成請求隊列，而 組件依次排列，就夠成了 WebSphere 排隊網絡。正如下圖所示，該排隊網絡包括互聯網、Web 服務器、Web 容器、EJB 容器以及數據庫端的連接池隊列等等。WebSphere 隊列裏的各個組件是互相資源依賴的，對請求的平均服務時間依賴於服務器隊列中每個組件在同一時間的最大併發數。
圖 2. WebSphere 排隊網絡
保守隊列和開放隊列
在組成 WebSphere 排隊網絡的隊列中，大部分都屬於保守隊列。對於保守隊列，我們可以設置某些參數來限制隊列中請求被處理的最大併發數，相反，開發隊列則沒有這樣的限制。與 開放隊列相比，保守隊列的好處是，可以使系統資源被有效的管理和利用，避免因爲資源耗盡而引起的系統崩潰。例如，在 Web 容器中，假設平均處理一個 servlet 請求要創建 10M 大小的對象，如果我們設置其最大連接數是 100，那麼這樣就可以將 Web 容器對內存的最大消耗控制在 1G 左右。因此，保守隊列使得系統管理員更有效的管理系統應用。
保守隊列中的用戶請求由兩種狀態，分別是激活狀態和等待狀態。當請求處於激活狀態時，表明該請求正在被服務器進行處理；當請求處於等待狀態 時，表明該請求還未被處理，而是在等待被激活，進而才能夠使用服務器資源。只有當一個處於激活狀態的請求被處理完畢離開隊列後，纔會有一個處於等待狀態的 請求被激活，否則該請求將一直處於等待狀態，直到服務器超時拋出異常，如果出現此種情況，則表明服務器需要進行系統優化。
在 WebSphere 服務器的隊列網絡中，Web 服務器、Web 容器以及數據庫連接池都屬於保守隊列。EJB 容器則繼承了對象請求代理（ORB）的隊列特性，屬於開放隊列。
在 WebSphere 中，我們主要通過最大和最小連接數兩個參數來對其隊列進行調優和設置，接下來我們會給出一個在進行 WebSphere 隊列調優時的一個基本準則。讀者在以後的調優中可以參照這個準則，然後結合自己的實際系統環境來進行隊列調優。
“漏斗”原則
WAS 調優的第一原則就是漏斗原則。一般來說，讓客戶不能及時得到處理的請求在網絡中等待，比讓它們在 WebSphere 服務器中等待要好。下圖的設置使得只有即將被服務器接受處理的請求才能進入 WAS 的排隊網絡，這樣更能提高服務器的穩定性，而不至於當大量請求突然進入 WAS 時引起資源耗盡的情況。要實現這個原則，那麼越往下游的組件，其處理請求的最大併發數應小於上游組件的最大併發數。如下圖所示，只有可以被處理的請求才會 進入相應的組件被處理，而大於該組件併發數的其他請求，則都處於排隊狀態，等待服務器接受處理。
圖 3. Upstream quening
在上圖的例子中，我們可以看出，在 WebSphere 排隊網絡中，從上到下隊列中處理請求的併發數越來越小。當 200 客戶端請求到達 Web 服務器的時候，因爲 Web 服務器設置了自己的最大併發數是 75，所以剩下的 125 個客戶請求只能暫留在網絡中進行排隊等待被 Web 服務器處理；當這 75 個請求經過 Web 服務器被處理後，其中 25 個仍在停留在 Web 服務器中排隊，而剩下的 50 個請求則進去 Web 容器被進一步處理；直到最後有 25 個請求到達最後的數據庫端，這時請求被處理完畢。在這個系統中，每一個組件都在充分的工作，沒有因爲等待請求到來而造成的資源浪費，因爲在任何一個時刻， 每個隊列裏都有少量請求在等待着被下一個組件處理。因爲大量的請求被阻止在 WebSphere 服務器的外面（網絡），所以 WebSphere 的各個組件不會因爲大量請求同時到來而引起資源耗盡，這樣的設置增加了系統的穩定性。
繪製吞吐率曲線
上面介紹了在對 WebSphere 服務器池資源進行調優時的一個最重要的準則，下面我們來介紹如何根據這個準則，並結合用戶實際的系統環境來進行調優設置。首先我們需要畫出系統在運行時的 吞吐率曲線，要完成曲線，需要準備一個測試用例，然後將系統運行起來，我們的目的是要將系統的潛能發揮到最大，即系統運行達到一個資源利用的飽和點。系統 運行達到飽和點最有代表新的特徵就是 CPU 的利用率接近 100%。
在運行測試用例的開始階段，我們將 WebSphere 排隊網絡中所有的隊列併發數都設置爲一個較大的值，而且各個隊列的值也設成是相等的。要保證這樣的設置可以使你的系統在運行時達到最大的處理能力。例如，將排隊網絡的每一個隊列的最大併發數都設置成 100。
現在，我們開始進行一系列的測試，根據測試數據繪出吞吐率曲線。在每一次的測試後，增加用戶併發數，迭代測試，例如：把用戶併發數設置成如下 一組數值進行一系列測試（1,5,10,25,50,100,150,200...），在每次測試後，記錄下本次系統的吞吐率和響應時間，就得到了類似於 下圖的吞吐率曲線。
圖 4. 吞吐率曲線
吞吐率是 WebSphere 服務器中在同一時間處理用戶請求的併發數，反應的是 WebSphere 處理併發請求的能力。從上圖中我們可以看出，曲線可以分爲三個階段，在第一階段，也就是 A 階段的時候，這時併發的數量比較少，吞吐率隨着併發數目的增加而增加。因爲在這個時候，併發數較小，隊列中幾乎沒有請求在排隊，每當一個請求到來時就能立 刻得到處理，隨着併發數的增加，在某一時刻，排隊情況開始出現，吞吐率曲線的增長變的緩慢，直到達到了系統處理能力的飽和點，這個時候也就是出現了系統的 性能瓶頸。最具代表性的系統瓶頸是，在飽和點時，系統 CPU 利用率幾近 100%，這時我們只要換上更加高性能的 CPU 就可以提高整個系統的性能。在經過飽和點後，吞吐率曲線進入第二個階段 B，這時，隨着併發數的增加，吞吐量並沒有增加，而是維持在一個穩定的水平。然而，客戶端所感受到的服務器響應時間則會隨着併發數的增加而加長，這時因爲 很多的請求都在隊列裏排隊，並沒有及時的被服務器處理。此刻，併發數繼續增加，就會進入第三個階段 C，這時，隨着併發數的增加，吞吐率反而會急劇下降，這時因爲系統中某一個組件負載過重，導致資源已經被消耗殆盡。
在進行曲線繪製的過程中，我們需要注意一個問題，如果在飽和點出現的時候，系統的 CUP 利用率接近 100%，那麼我們就能進行進一步的調優設置了；如果 CPU 利用率沒有達到 100%，那麼就說明，系統中所運行的應用程序存在問題，也就是性能瓶頸所在。比如，你的應用程序可能創建了很多的大對象，導致了 JAVA 中的頻繁 GC，大量佔用系統資源而出現性能瓶頸，對於性能瓶頸，我們需要認真檢查程序源代碼，找出問題所在，然後修改排查，消除因爲應用而造成的系統瓶頸。找出性 能系統瓶頸的方法很多，不是本文論述的重點，讀者可以參考其他資料來進行排查。
隊列初調
在吞吐率曲線達到飽和點時的用戶併發數是系統應用所能處理的最大併發數，這也是 A 階段和 B 階段的分界線。這個值將做爲我們調整隊列大小的一個基準值。如上圖所示，飽和點時，併發數是 50，我們選擇 48 來做爲調整隊列的基準值，因爲在此刻吞吐率和響應時間都是最佳的，這個值稱爲程序所能處理請求的最大併發數。正如我們前面所介紹的，理想的情況是確保大量 的等待請求處於網絡中，而不是 WebSphere 服務器中，所以參照“漏斗”原則，我們可以對 WebSphere 服務器中的各個組件的最大併發數進行如下設置：Web 服務器 , 75，Web 容器 50，數據庫連接池 45。然後我們在進行一系列的測試，對這些值進行微調，以使系統的性能達到最優。
根據應用的實際情況來調整隊列
僅僅根據上面的準則來調優 WAS 是遠遠不夠的，我們還應根據應用的使用環境和訪問模型來調整各個隊列的大小。並不是所有的請求都會從上一個隊列進入到下一個隊列中，比如，有些請求可能在 經過 Web 服務器處理後就返回給客戶端了，因爲這些用戶僅僅是想請求一些靜態的頁面內容，這時我們可以將 Web 服務器的隊列值設的大一些，我們上面將 Web 服務器設成 75 就是這樣的考慮；又比如，如果在一個應用中，大部分的請求都需要進行復雜而耗時的數據庫操作，這時我們就應該考慮同時加大數據庫連接池和 Web 容器的隊列值大小。所以，在我們實際的調優中，必須結合具體的應用來確定合適的值，並在不斷調整的過程中，監控 CPU 和內存的使用，避免系統資源耗盡的情況出現。
我們在這裏給出 WebSphere 池資源調優的一些建議，但真正合適的大小還要參考實際情況，調優是一個循序漸進的過程，需要經過不斷的嘗試和修改才能最終達到系統設計所需要的最佳性能。
當配置 ORB 線程池的時候，需要了解 EJB 客戶端對應用的訪問模式。比如，如果在一個 servlet 中只是有很少的 EJB 調用，而且每一次方法調用的時間相對很短，那麼你就應該調整 ORB 線程池的值儘量小於 Web 容器的最大併發數。
圖 5 . EIB 調用模式
並行調用 EJBs 的 servlet 的數量和每次方法調用所持續的時間是我們調整 ORB 線程池大小的兩個依據。如上圖，是兩種在 WAS 裏從 servlet 中調用 EJB 的場景。第一種場景中，servlet 主要做一些持續時間非常短的遠程調用，servlet 可以重用已經存在的 ORB 線程。在這種情況下，ORB 線程池可以設的比較小，例如只要設置爲 Web 容易最大併發量的一半就行；第二種場景中，持續時間比較長的 EJB 調用將會長期的佔用 ORB 連接，因此該連接被重用的機會很小，所以在這種場景中，最好將 ORB 線程池的大小與 Web 容器的最大併發量設置成相等，或者更大。可以使用 WAS 管理控制檯進行 ORB 線程池的配置，位於 Application servers > AppServer name > Thread pools > ORB.thread.pool
一般來說，每個服務器 CPU，5 至 10 個線程將會提供最佳吞吐量。另外我們也可以利用 WAS 自帶的 TPV 來幫助我們設置 Web 容器線程池。對系統做一個壓力測試，保持一定的負載，觀測 TPV 中的PercentMaxed 和 ActiveCount的值，PercentMaxed
表示所有線程被使用的平均百分比，如果該值較大，那麼就應該增大線程池的值；ActiveCount 表示被激活的線程個數，如果該值遠小於當前線程池的大小，那麼可以考慮減小線程池的值。可以 使用 WAS 管理控制檯進行 Web 容器線程池的配置，位於 Application servers > AppServer name > Thread pools > WebContainer
當我們連接任何數據庫時，數據庫連接的初始化是一個非常耗資源的操作，所以當性能問題出現時，只是一味的加大數據庫連接池往往並不能提高性 能。通常的做法是，首先將數據庫連接池的大小增大一倍，看看是否可以解決性能問題，如果可以，再逐步減少數據庫連接池的值，找到性能瓶頸以及達到最優性能 時連接池的大小。一般來講，數據庫連接池的值小於 Web 容器線程池的值是比較好的選擇。
在實際的環境中，我們可以利用 TPV 去監控數據庫連接池的使用情況，以此來調整數據庫連接池的大小，從而確定最優的調優策略。可以從 TPV 的以下監測值中尋找答案。
表 1. TPV 監控列表
監測值名稱 描述 調優策略 PooSize 連接池的大小 PooSize 會隨着新連接的建立而增加，會隨着連接的銷燬而減少；應該爲連接池設立一個最大值。 PercentUsed 連接池線程被使用的百分比 如果該值長時間都很小，那麼你應該調小 PooSize，反之應該增大。 WaitingThreadCount 單位時間內正在等待建立數據庫連接的線程的個數 系統最佳的性能體現在該值總是保持在很小的數目，如果該值偏大，則需要對系統進行調優 PercentMaxed 數據庫所有連接都被使用的時間所佔的百分比 確保這個值不會長時間的達到 100%，如果是那樣，那麼你該考慮增大 PooSize 值
可以使用 WAS 管理控制檯進行數據庫連接池的配置，位於 JDBC providers > Provider name > Data sources > Data source name > Connection pools
在本文中，我們詳細的討論了 WebSphere 服務器中池資源的概念以及調優，並在介紹 WebSphere 排隊網絡的基礎上，闡述瞭如何在實際的生產環境中進行池資源配置。通過閱讀本文，讀者可以基本掌握 WebSphere 性能調優的一般準則，並能初步掌握性能優化的一些技巧和方法。
學習
- WebSphere Application Server V7 信息中心 ：瞭解更多 WebSphere 產品的信息
- WebSphere Application Server V6 Scalability and Performance Handbook
- 瞭解 EJB 調用如何在 WebSphere Application Server 中操作
- IBM developerWorks 中國 WebSphere 專區：爲使用 WebSphere 產品的開發人員準備的技術信息和資料。這裏提供產品下載、how-to
信息、支持資源以及免費技術庫，包含 2000 多份技術文章、教程、最佳實踐、IBM Redbook 和在線產品手冊。
獲得產品和技術
- 最受歡迎的 WebSphere 試用軟件下載：下載關鍵 WebSphere 產品的免費試用版。
- IBM developerWorks 軟件下載資源中心：IBM deveperWorks 最新的軟件下載。
- IBM developerWorks 工具包：下載關鍵 WebSphere 最新的產品工具包。