對於絕大多數部署在高性能服務器上的應用來說，大量的並發操作是不可避免的。在相關配置參數未經過充分調優的情況下，即使有時系統資源的利用率並未達到峰值，在增加工作負荷的同時，系統資源的利用率卻仍未得到提高。所以為了確保服務器有能力處理與其處理器性能相匹配的高工作負荷，需要針對最大並發量進行調優。
值得注意的是，更多的並行處理意味着對服務器資源（例如內存和線程數）的更高需求，這就需要同時協調其他的調優目標，例如對大對象的處理，應對大規模用戶，提供快速反應等等。為優化在最大並發量下的操作，我們在調優過程中需遵循這一指導方針——沿着執行流程，逐個去除瓶頸。
回頁首
在多並發環境中對邊緣組件 (Edge Component) 進行調優
首先對結合業務場景，按照邊緣組件的綁定的不同，分別加以描述與分析。
1 Java 消息服務 (Java Message Service, JMS) 綁定和 MQ 綁定
3 企業信息系統 (Enterprise Information System, EIS) 綁定
然後按照邊緣組件處理的業務對象的來源，分別介紹調優相關的參數和配置。
2 如果輸入業務對象來自 J2EE 連接器架構 (Java EE Connector Architecture, JCA) 1.5 資源適配器（非 SIB JMS 資源適配器）
4 如果輸入業務對象來自對象請求代理 (Object Request Broker, ORB) 請求
邊緣組件主要是指導出 (Export) 和導入 (Import) 組件。導出組件定義了一個模塊的外部接口，從而使得該模塊的服務組件架構 (Service Component Architecture, SCA) 組件可以為外部客戶端提供服務。導入組件定義了一個針對模塊外部服務的接口，通常被 SCA 組件用來調用採用了 SCA 編程模型的外部服務。 圖 1 是在 WebSphere Integration Developer 業務集成界面上的一個名為 PerformanceTuningTest 的模塊實例，圖 1 中綠色實線框內的組件均為導出組件，紅色虛線框內的組件均為導入組件。
圖 1. 模塊實例 PerformanceTuningTest
在多並發環境中，首先需要確保 WPS 的邊緣組件並發地接收，發送和處理業務對象。本節首先按照綁定方式的不同，結合真實的業務場景分別介紹邊緣組件調優需要涉及到的配置信息；但由於這些綁定涉及到的配置信息互有重疊，本文將在後面的章節對這些配置信息按照處理的數據對象的不同加以分類介紹。
1 Java 消息服務 (Java Message Service, JMS) 綁定和 MQ 綁定
JMS 綁定共有三種，分別是 JMS1.1 綁定 , 通用 (Generic) JMS 綁定和 WebSphere MQ JMS 綁定。JMS 綁定、 MQ 綁定與後面即將介紹的 HTTP 綁定統稱為消息綁定 (Messaging Binding) 。圖 1 中包括了這裡提到的四種綁定的導入、導出組件。
在請求 – 響應方式下，導出和導入組件都會涉及到接收，處理和發送消息的操作。首先，如何在大量外部服務請求消息並發到達的情況下高效地進行接收是決定多並發環境性能的關鍵要素。導出、導入組件通過消息驅動 Bean (Message Driven Bean, MDB) 來監測請求、響應消息的到達。按照綁定方式的不同，可採用不同的配置方式決定 MDB 並發能力的高低。在圖 2, 3 中，綠色虛線框內描述了不同綁定中消息接收的工作原理和相應實現。
如圖 2 所示，對於 JMS 綁定，JMS 激活規範 (JMS Activation Specifications，ActivationSpec) 被用來綁定 MDB 和驅動 MDB onMessage() 方法的消息隊列，以及定義一系列 MDB 相關參數。所以為提高並發接收消息的能力，需要對 JMS 激活規範進行配置。圖中粉色五邊形代表了 JMS 綁定導入、導出組件相應的激活規範（命名規範詳見藍字），灰色長方形代表了 MDB 監聽的服務集成總線 (Service Integration Bus，SIBus) 上的目標 (Destination) （命名規範詳見藍字）。具體調優過程和參數詳見後文 配置 JMS 激活規範 部分。
圖 2. JMS 綁定導入 / 導出組件接收 / 發送消息原理圖
對於 MQ 綁定， MQ JMS 綁定和通用 JMS 綁定，MDB 的偵聽器端口 (Listener Port) 被用來實現與 JMS 激活規範類似的功能，同理也需要對偵聽器端口進行調優。需要注意的是在使用偵聽器端口來定義 MDB 的情況下，還需要對相應的 JMS 連接工廠 (Connection Factory) 進行配置，以保證為所有 MDB 線程提供到 JMS 提供程序 (JMS Provider) 的連接，例如默認消息提供程序 (Default Messaging Provider) 、 WebSphere MQ 消息提供程序 (MQ messaging provider) 等。圖 3 中橙色正方形代表了 MQ 、 MQ JMS 、通用 JMS 綁定導入、導出組件相應的偵聽器端口（命名規範詳見藍字）；灰色長方形代表了 MDB 監聽的 MQ 或其他 JMS Provider 上的目標（命名規範詳見藍字）；黃色圓形代表了連接工廠（命名規範詳見藍字）。對偵聽器端口和連接工廠的具體調優過程和參數詳見後文中 配置偵聽器端口 和 配置 JMS 和 JMS 隊列連接工廠 部分。
圖 3. MQ, MQ JMS, Generic JMS 綁定導入 / 導出組件接收 / 發送消息原理圖
根據業務需要有時要將響應 / 請求消息發送給外部服務。如圖 2 和 3 中紅色虛線框中描述的那樣，導入 / 導出組件通過連接工廠連接到 MQ 或 JMS 提供程序。以導入組件為例，對每一個消息綁定導入組件，根據開發時選擇配置新消息提供程序資源或指定已經配置好的消息提供程序資源，在部署應用程序過程中會生成一個連接工廠，或指定已配置好的連接工廠。該 JMS 連接工廠連接池的最大連接數屬性應該足夠大，以保證為導入組件中並發執行的所有發送消息的線程提供連接。同樣，對連接工廠的具體調優過程和參數詳見 配置 JMS 和 JMS 隊列連接工廠 部分。
通過對 MDB 的激活規範，偵聽器端口和連接工廠進行調優，導出 / 導入組件可以實現並發接收和發送消息，接下來的瓶頸則是如何對這些消息進行並發的處理，也就是要求多個 MDB 線程並發運行。這就需要對 MDB 的線程池進行調優，包括對默認線程池的調優，和專用線程池的設置。具體的調優參數詳見後文。
針對 SOAP/HTTP Web Service 綁定和 HTTP 綁定，調優的重點應該放在網絡容器 (Web Container) 的線程池 (Thread Pool) 上，從而保證能提供足夠的線程對請求進行處理。具體的調優參數和指導詳見後文 如果輸入業務對象來自 HTTP 調用 部分。
針對 SOAP/JMS Web Service 綁定，由於它的底層傳輸協議是 JMS ，所以對 SOAP/JMS Web Service 綁定邊緣組件的調優與針對 JMS 綁定的調優類似。在部署含有 SOAP/JMS Web Service 綁定邊緣組件的應用過程中，默認生成 JMS 隊列 jms /< 導出組件名 >，用於監聽這個隊列的 MDB ，相應的 JMS 激活規範，以及隊列連接工廠。對這些配置的調優建議詳見後文中 配置 JMS 激活規範 和 配置 JMS 和 JMS 隊列連接工廠 部分。
3 企業信息系統 (Enterprise Information System, EIS) 綁定
當使用外部 JCA 資源適配器的時候，EIS 綁定可以幫助調用 EIS 上的服務 / 資源或使您的服務對 EIS 可用。 JCA 資源適配器使用 J2C 激活規範來配置特定 MDB 實例，使用 J2C 連接工廠在運行時創建出站連接實例。所以針對 EIS 綁定邊緣組件的調優重點在 J2C 激活規範和 J2C 連接工廠上，配置界面如後文中 配置 J2C 激活規範 和 配置 J2C 連接工廠 所示，但是具體的調優參數請參考 JCA 資源適配器調優相關文檔。
對於同步 SCA 調用，在 SCA 模塊的部署過程中，將為該模塊生成一個用於為服務請求者提供同步調用接口的無狀態會話 (Stateless Session) Bean，以及一個指向它的名稱的空間綁定 (Namespace Binding) 。所以對同步調用導出組件的調優主要關注處理 EJB 請求的線程池規模，詳見後文 如果輸入業務對象來自對象請求代理 (Object Request Broker, ORB) 請求 部分。
對於異步 SCA 調用，在 SCA 模塊的部署過程中，將在 SCA.SYSTEM.<cell name>.Bus 上創建一些 SIBus 目的地，通常情況下是一系列隊列，同時還會生成相應的 J2C 激活規範來配置監聽這些目的地的 MDB 。所以，在多並發環境下，異步調用中的 SCA 綁定導入和導出組件，需要對 J2C 激活規範進行調優，從而保證更多的並發消息被 MDB 接收和處理。這裡我們以一個業務場景為例簡單描述異步調用 SCA 綁定邊緣組件的工作原理和相應構件。
該業務場景由兩個模塊組成，Module1 採用異步回調方式調用 Module2。在部署這兩個模塊時，會在系統總線上自動生成 4 個目的地： SCA/Module1; SCA/Module2; SCA/Module1/importlink/Module1_SCABindingImport 和 SCA/Module2/exportlink/Module2_SCABindingExport ，以及兩個 J2C 激活規範：Module1_AS 和 Module2_AS。
其中 SCA/Module1 和 SCA/Module2 均為模塊隊列，由 Module1_AS 和 Module2_AS 相關聯的 SCA 模塊 MDB 對其進行監聽。灰色虛線部分代表了請求發送的路徑，在部署期間，將會在 SCA/Module1/importlink/Module1_SCABindingImport 上創建缺省轉發路由路徑。從而在消息到達此目的地後，將消息自動轉發到 SCA/Module2/exportlink/Module2_SCABindingExport，同樣，SCA/Module2/exportlink/Module2_SCABindingExport 上也定義了缺省轉發路由路徑，因此在消息到達此目的地時，消息將被轉發到 SCA/Module2 目的地。並由 Module2_AS 定義的 MDB 接收並處理該請求。該 MDB 從消息正文獲取請求消息，並從消息頭中獲取目標服務名稱。然後它將請求分派給某個 SCA 運行時 (runtime)。SCA 運行時處理消息並調用目標服務，如果存在任何響應，SCA 運行時將響應消息寫回到存放在消息頭中的響應目的地，在本業務場景中，即為 Module1 的模塊隊列 SCA/Module1。同樣，Module1_AS 相應的 MDB 監聽到了該響應，並進行後續的操作。從這個流程中可以看出需要進行調優的主要是 Module1_AS 和 Module2_AS。具體的調優參數及指導詳見 配置 J2C 激活規範。由於 SCA 模塊 MDB 是由該模塊中所有組件共用的，本文在中間組件調優部分中還會對其進行詳細介紹。
在 WPS 中， EJB 綁定只能應用於導入組件上。通過 EJB 綁定， SCA 模塊能夠通過 IIOP (Internet Inter-ORB Protocol) 協議調用運行在 J2EE 服務器上的基於 J2EE 的應用程序。被調用方應提供足夠的線程來處理 EJB 調用請求。
JMS 激活規範的最大並發端點數 (Maximum Concurrent Endpoint) 決定了相應的 MDB 可以並發接收的消息數量。它的默認值是 10，這意味着同時可以有 10 個業務對象從 JMS 隊列中被傳遞給 MDB 線程。如果需要並發處理 100 個，則需要將該值改為 100。但是值得注意的是，一個活躍的 MDB 實例在容器線程池中的一個線程上運行。
這裡您可以使用 Tivoli Performance Viewer(TPV) 來檢測最大並發端點數。對於每一個正在被 MDB 處理的消息，在隊列中將有一個消息被標誌為鎖定在一個事物中（這個鎖將在 onMessage() 方法完成時被移除），同時這些信息被標誌為”不可用”。可以通過一個性能監控基礎結構 (Performance Monitoring Infrastructure， PMI) 度量參數來查看每一個隊列中不可用消息的數量（性能模塊 > SIB Service > SIB Messaging Engines > 總線名 > Destinations > Queues），這被稱為”不可用消息數 (UnavailableMessageCount)”。如果任一隊列中存在至少與最大並發端點數相同數量的不可用消息，則意味着當前 MDB 的最大並發端點數限額已經成為瓶頸，此時，需要增大 MDB 的最大並發端點數。
圖 5. 通過 Tivoli Performance Viewer 查看 PMI 不可用消息數
以下文章點擊率最高
Loading…