IBM WebSphere DataPower Appliances （以下簡稱 DataPower）的構建目標是快速部署系統集成和安全政策。讓固件和硬件組件相匹配，以便在硬化和易於管理的平台中優化策略執行。DataPower 加快了實現價值的速度，降低了這些復雜的基礎體系結構的總擁有成本。
DataPower 配置往往通過與其他服務的集成來實現解決方案。例如，通過訪問一個集中式目錄（LDAP），可以制定安全策略決策。通過注冊表和存儲庫系統，可以獲得企業策略。通過訪問 SYSLOG 資源，可以執行日志記錄。通過數據庫訪問，可以轉換或 “豐富” 消息。此類功能通常在將消息傳遞給下游應用程序進行處理之前執行，在響應被返回給客戶端之前，對應用程序的響應可能會進行額外的處理。
這種集中式拓撲證明了 DataPower 的敏捷連接功能。然而，每一個集成都可能為成功處理流帶來延遲或限制。雖然一些交互可能是異步或 “即發即棄（fire and forget）”的，但其他交互將是同步的，而且需要先完成它們，後續操作才可以開始。在這兩種情況下，事務都可能要排隊，並消耗設備資源，以等待事件完成。DataPower 硬件平台提供更快的接口、擴展的內存和更快的 CPU，在極端情況下，這些事件可能會限制以最佳速度處理事務的能力。
有一些最佳實踐可以管理這些交互。可以安裝監控器來跟蹤事務數據的傳入率，並處理每個事務所需的持續時間。可按照預定速率來 “調整” 和處理事務。可以配置服務水平協議和服務水平監控器，使其具有復雜的中介功能，它們可與企業治理資源配合使用，這些資源包括 WSDL、WS-Mediation 和 WebSphere Registry and Repository（WSRR）。
本文將討論和演示一些技巧，使您的 DataPower 配置對於集成依賴關系的差異更具彈性，提供更強大的 DataPower 體系結構。我們將介紹各平台和固件版本的 DataPower 資源的一些基本知識，並復習資源監控的基礎知識。然後，我們將探討一些最佳實踐，可以通過實現它們來優化 DataPower 服務。
DataPower 在固件和硬件設計中不斷改進。DataPower 的設計有多種外形規格，包括 1U、2U、Blade 和 Virtual 版本。在這些設備內，存在物理特性的差異。我們將介紹這些差異中的部分差異，以及資源分析的一些基礎知識。
目前的 DataPower 硬件 71XX 平台（7198 和 7199）提供 1U 和 2U 設備。包括 9235（9004）在內的前幾代 DataPower 硬件平台提供了 1U 型號。雖然本文所述的許多主題與所有 DataPower 硬件平台（包括 Virtual 版本）有關，但我們會將重點放在目前這一代，即 71XX/4195 平台。
如表 1 所示，7198、7199 和 4195 Blade 型號的物理內存和硬盤空間量各有不同。
最近 DataPower 固件版本（5.X）利用擴展的內存支持提供增強的處理能力，在 XG45、XI52、XI50B 和 XB62 上實現更大規模的消息處理，並支持更高的並發性。需要這些最新型號才能充分利用 5.X 的擴展的內存功能。您可以在上一代硬件（比如 XI50、XS40 和 XA35 型號的 9235 設備）上使用 5.X。您可以在 XG45、XI52、XB62 和 XI50B 上運行 5.X 之前的固件版本，但只有在 XG45、XI52、XI50B 和 XB62 才能充分利用 5.X 增加的功能。
查看本欄目
DataPower 提供許多 “狀態提供者”（或監控代理），它們內置於 DataPower 的固件中，用於抓取狀態數據。這些提供者用於確定組件的健康狀況，這些組件包括風扇、溫度傳感器、物理內存、CPU，等等。
雖然幾個狀態提供者是系統資源利用率的指標，但內存是一個不錯的事務效率指標，我們在這裡將回顧一些特定的內存狀態信息。可以從 WEBGUI（如圖 1 所示）或通過使用命令行界面（CLI）、XML 管理接口（XMI）來提取狀態數據，也可以通過查詢系統網絡管理協議（SNMP）管理信息塊（MIB）來提取狀態數據。每種技術都將提取供應者的當前狀態信息。
Memory Usage 報告中顯示的內存類別乍一看有點混亂。主要問題出在設備上的物理內存總量（安裝內存）與 DataPower 固件的可用量（總內存）上。如果 DataPower 從它的操作系統請求一個內存塊，並使用它所需的要求，它通常被返回到保持隊列中，而不是返回到操作系統。只有在內存限制的期間，或者在系統回收時，它才會被返回到操作系統。因此，所請求的內存通常能夠保持平衡，甚至隨著時間的推移而增長。表 2 顯示了內存類別。
通過命令行界面的 “Show Load” 命令或 "System Usage"（參見圖 2）狀態提供者，可以提供 DataPower 資源的另一種分類。System Usage 顯示在設備上運行的多個任務的數據，而不只是顯示主要的 DataPower 任務。這些值被顯示為在某一 “間隔” 內的百分比，通過 “load-interval” 命令可以修改此間隔。其他任務包括 DB2、SSH，以及可能作為副進程並且不在 DataPower 地址空間內運行的其他任務。
系統使用考慮到了所有已分配的資源，不管它是正被有效使用，還是僅處於預留狀態。在使用 DataPower 支持資源問題時，這些值有時會提供幫助。然而，對於容量規劃而言，來自顯示內存狀態提供者的內存使用情況信息是更准確的指標，因為預分配內存可供 DataPower 重用。
查看本欄目
DataPower 通過 Multi-Protocol Gateway (MPGW) 或 Web-Service Proxy (WSP) 等服務來實現事務處理。通常是在域內配置服務，以實現便捷的生命周期管理和其他管理效益。處理策略是使用一些用來實現規則和規則包含操作的容器。這些操作通過執行 Extensible Stylesheet Language (XSL) 轉換實現了一些更高級的功能，比如數字簽名、加密和身份證，或自定義處理。讓我們回顧一下為這些服務確定內存要求的一些方法。
經過最近幾個版本的改進，內存信息已得到增強，可以顯示域和服務的增量利用率，並提供了 XSL 和 XML 文檔緩存。有關您的特定固件版本的完整內存狀態信息，請參閱信息中心。圖 3 顯示了域內存利用率的一個示例。請注意，顯示中包括時間增量、服務壽命（從上次啟動），以及文檔和樣式表緩存的值。如果有興趣確定可能會占用過多內存的配置區域，那麼請查看域內存統計數據是一個良好的起點。
在識別感興趣的區域後，您隨後可能會想了解域內的服務，以及它們是如何利用內存的。從默認域或從一個應用程序域，可以顯示特定的服務及其內存使用率。圖 4 顯示了服務狀態信息的一個示例。
查看本欄目
自從前面提到的 developersWorks 文章 發布（DataPower 版本 3.8.2）以來，已添加了更多的內存狀態信息。具體來說，現在，一個新的日志類別 "memory-report（內存報告）" 產生了有關每一個操作在一條處理規則內的內存利用率的詳細信息。例如（如圖 5 所示），一個樣例規則執行演示了用於確定由簽署操作、驗證操作、轉換操作和事務使用的內存總量的能力。這在自定義 XSLT 操作中特別有價值。使用低效的 XPath 或模式的 XSLT 通常會被優化，以減少內存占用。該報告顯示用於初步解析的內存信息，並將傳入消息的模式驗證和每個操作和規則相關聯。這個特定事務中的簽署操作使用的內存比它前面的簡單身份轉換使用的內存資源要多，鑒於其復雜性，這種情況也是在預料之中。
有多種因素會影響內存利用率。消息大小和並發性是顯而易見的因素。當事務被處理時，DataPower 流的速度不僅受到 DataPower 所應用的 “工作” 的影響，還受到與 “第三方（off box）” 資源的交互的影響。例如，日志記錄步驟可能取決於日志記錄資源的成功或失敗。應用程序資源可能最終必須處理事務，而來自該應用程序的響應可能需要進一步處理。在這一節中，我們將更詳細討論一些內存利用率要素。
在使用固件版本 5.0 和硬件型號 719x 平台時，可以處理大規模的消息。雖然每個環境都具有惟一性，每一個消息的復雜性和結構都不同，但要對多個千兆字節的消息進行處理是有可能的，其中包括數字簽名和加密處理等復雜的操作。在處理 XML 或 SOAP 消息的時候，以及在處理這些文檔的策略中使用操作的時候，要需要考慮的一個因素是所需的 “解析”。解析是對一個進入可動態訪問的對象結構的輸入字節流的處理，該操作需要的內存明顯大於輸入流本身。此資源需求在執行並發處理的時候成倍增加。我們很快會看到，在沒有完全解析的情況下 “流線化” 消息，從而實現對無限大小的消息的有效處理。
DataPower 操作可能會 “同步” 執行（即後續操作要等待前面的操作完成），或 “異步” 執行（即操作並行地運行）。默認情況下，操作是同步的，每個操作都會等待其前一個同級操作完成。通常情況下，這是所期望的行為。身份驗證和授權（AAA）或服務水平監控（SLM）等特定操作應該同步運行，因為後續操作要在它們成功執行的基礎上執行。然而，對於某些策略規則，可以並行運行操作。例如，將日志數據發布到外部服務。如果日志服務器變慢，而且日志事件是非關鍵型的，您可能不希望客戶的事務被延遲。
然而，異步操作不是免費的。優化 DataPower 的主要目的是盡量減少延遲。當事務執行規則中的每一個操作時，直到事務完成，它才會釋放所使用的內存。它將內存放在一個 “事務或保持” 緩存中，供後續操作使用。只在整個事務已經完成後，內存才是空閒的。直至此時，它才可以供另一個事務使用。
在集成服務響應很慢的情況下，異步操作可能會過度使用資源。考慮一個將 SOAP 消息發送到外部服務器的操作。這一操作的結果並不是事務流的一部分，您不想因等待來自服務器的確認而延遲對客戶端的響應。可將該操作標記為異步。假設，外部服務器通常在 10 毫秒（ms）後就以 HTTP 響應進行響應。
現在，假設您的設備有一個溫和的 100 事務每秒（TPS）流，並且外部日志服務器速度緩慢，對每個 SOAP 消息的響應需要 10 秒。假設每個事務使用 1MB 內存來解析和處理請求事務。突然，日志操作在等待來自日志服務器的 HTTP 響應時持有 1GB 內存！這很快就會導致設備開始延遲有價值的流量，以防止過度利用資源。如果此日志記錄不是業務關鍵型的，那麼您可能希望在主要數據流量受到影響之前中止日志記錄操作。我們將介紹如何使用控制或 “門面” 服務實現此操作，如在 實現服務水平管理 中所述。
文檔解析的替代方法是通過一個服務策略實現文檔的 “流線化”。在該場景中，通過一個策略規則一個部分接一個部分地傳遞文檔，同時無法訪問整個文檔，這通常就是所有的要求。在流線化模式中，內存的要求大大降低。流線化要求嚴格遵守處理的限制，包括可能調用的 XSLT 指令。例如，XSLT XPath 指令不能處理文檔的當前 “節點” 以外的文檔部分，因為它將是不可用的。
雖然流線化功能可以處理非常大型的文檔，但您必須滿足以下要求。您需要創建流線化規則，並編譯和檢查選項策略，以確保您的 XSLT 符合流線化的限制。
查看本欄目
在定義處理策略規則時務必小心，避免不必要的內存使用。大多數操作會創建輸出 “上下文”，但要認識到的重要一點是，每一個新的上下文都代表內存中的另一個分配。圖 6 顯示了一個示例，兩個轉換操作創建上下文（ContextA 和 ContextB），然後通過一個結果操作將上下文發送到輸出流。
在許多場景中，您可以使用特殊的 “PIPE” 上下文，以避免創建此中間上下文。PIPE 上下文並不要求每個處理步驟都有單獨的內存，而且它還有其他性能優勢。雖然有些操作需要有一個中間上下文，但在某些情況下，您需要使用不連續的處理模式，您應該確保對每個處理策略進行評估，以實現最佳的上下文使用。
關於上下文的另一個重要工具是使用特殊的 “NULL” 上下文。當操作不產生有意義的輸出時，這個 “位桶（bit bucket）” 非常有用。也許您需要處理的只是日志一些數據，或者只是設置一個動態路由。如果您不修改消息，那麼後續操作可以訪問原始輸入數據，並且您不需要傳遞它與 XSLT "Copy" 語句，產生不必要的上下文。
查看本欄目
延遲和超時是內存消耗的重要因素。考慮一個典型的場景：通過 DataPower 在後端服務上處理請求。事務率很高，吞吐量卻和預期的一樣。現在假設後端服務響應變慢，但它仍有響應，而且沒有超時。請求按照先前的速率進入 DataPower，並不知道下游服務上的速度已經放緩。但是，直到收到來自後端的響應，而且可能要在響應規則內對響應進行處理，然後才可以完成事務。DataPower 必須維護請求數據和在響應規則處理過程中產生的變量。
此外，延遲可能沒有與服務的 “後端” 關聯，而是由其他端點在請求或響應規則處理過程中訪問。因此可能會發生很多種交互。然後可能會調用日志記錄、身份驗證、整合流程或其他集成服務。如果它們響應很慢，事務的完成也就很慢。如果以連續的速度接受事務，事務就會開始排隊，處於活動的和未完成的狀態。這些事務一直占用資源，直到完成它們。
後端超時值是在服務中設置的。默認值通常是 180 秒，該值控制了事務之間的初始連接以及連接維護。用戶代理設置（從服務的 XML Manager 對象確定）用於指定 “第三方” 或跨規則請求的超時值。默認值是 300 秒。這個值可能太大，應該使用限制更嚴的值，當在現實的時間內無法建立連接時，允許連接失敗。超時因不同端點類型（HTTPS、ODBC 等）而有所不同，使用擴展功能可以動態地改變超時值。關於您的具體服務配置，請參閱產品文檔。
超時可通過日志消息識別，並利用消費這些事件的日志目標對超時進行分析。延遲可能具有更大的危害。您可能不知道延遲增加了（除非您在監視這些值）。然而，您可以使用監控技術（如 SNMP 監控器）查詢服務速率和持續時間監控器。有些客戶通過 XSLT 來利用延遲計算器，而且可以創建日志消息，日志目標可以使用此消息進行動態配置或分析。
DataPower 持續監視系統資源，包括內存和 CPU。為了避免資源的過度使用，節流設置允許暫時保留傳入的事務，直至約束被解除。如果使用這些節流設置，則允許在運行中的事務完成後再接受其他事務。在典型的高可用性環境中，事務由 HA 對等體組中的其他設備處理，以緩解飽和設備上的負載。圖 8 顯示了用於節流的默認值。在本例中，當內存為可用內存的 20％ 時，固件將等待 “超時” 秒數，然後重新評估內存。如果沒有清除內存限制，那麼固件將會重新啟動。無論任何時候內存低於 “Terminate At” 值，都會立刻進行重啟。
在等待資源釋放時，您可以使用積壓隊列保存傳入的事務。“Backlog Size” 的數量或事務（目前限於 500）的最大排隊時間是 “Backlog Timeout” 秒。如果積壓大小采用默認值 “0”，在節流過程中，事務會立即被拒絕。在節流進程對內存和其他資源進行評估的時候，可以將它們配置為生成詳細的日志消息。將 “Status Log” 從默認的 "off" 設置為 “on”，這樣可以產生如清單 1 中所示的消息。捕獲 Memory、Port、Free space 和 File System 的快照。與所有的日志消息一樣，您可以將這些事件發送到一個進程進行進一步的處理。例如，該進程可以是另一個 DataPower 服務，它執行 XML 管理命令來修改配置設置。
您現在了解了一些自己可用的資源。了解了如何使用內存數據來深入域、服務和每個操作，從而了解什麼地方正在消耗內存資源。接下來，我們將討論一些工具，它們對於執行事務流的動態分析很重要，並且可以用來影響事務速率。稍後，我們將討論事務流有關與第三方設備上的服務（如日志服務和後端資源）進行交互的關鍵問題。您會看到它們如何極大地影響事務流，以及您如何使用服務水平監控工具來緩解這些問題。
DataPower 服務通過專用的硬件和固件提供一個非常高效的處理環境。不過，要控制接受和處理事務的速率也有很好的理由。我們已經討論過 DataPower 和外部服務之間的相互關系。您不想采用超過外部服務對事務的處理能力的速度來接受事務。您可能還需要提供不同的服務水平。您的 “金牌” 客戶可以獲得比 “通牌” 客戶更高的處理速率的保證。
在本節中，我們將介紹可用來完成這些目標的一些基本配置選項。我們會介紹計數和持續時間監控器，以及服務水平管理策略，它擴展了監控器的功能，使其有更多選項，並能夠定義多條 “規則”，以支持復雜的服務水平監控。
DataPower 服務管理選項遠遠超出了這些基本功能，並且還包括與 WSRR 的集成。WSRR 提供了組織治理功能，包括策略定義和自動服務配置。您可以在 WSRR 中定義策略，並自動創建 DataPower 配置。我們鼓勵您研究這些功能，請參閱本文的 參考資料 部分。
查看本欄目
計數監控器和持續時間監控器提供了一種簡單的事務控制方法。這兩個監控器在工作時選擇性地執行 “篩選操作”。篩選操作可以調整或拒絕事務，或者只是生成日志消息。當然，日志消息可以觸發日志事件，包括監控操作和警報。
調整涉及到對事務進行排隊，以進行後續處理。選擇調整消息應謹慎。利用調整可以將短暫和臨時的網絡高峰時間內必須拒絕的事務的數量降到最低。例如，如果後端服務器正在經歷一段高利用率時間，並開始顯示出更長的延遲，那麼 DataPower 可以限制流到該服務器的流量，讓服務器的速度可以恢復。如果周期相對短暫，那麼 DataPower 在內存中排隊若干個事務，可能比拒絕它們是更好的選擇。當後端延遲降低時，可以釋放事務。這樣做的好處是可以減少客戶端所看到的錯誤的數量。
調整的缺點是需要更多內存來保存（排隊）事務。如果高峰期過長，在可以釋放事務之前，資源可能會受到限制。一旦事務被接受到調整隊列中，就無法取消該事務。隊列的大小是固定的，不能夠對其進行配置。在選擇使用調整時，這些都是重要的考慮因素。
在持續時間監控器的篩選計算中，一個重要因素是持續時間監控器測量要完成事務的平均時間。值得注意的是，該算法只考慮最後幾個事務的平均時間。它不是單個事務的絕對限制。一個常見的用例是配置一個監控器，如果服務的平均總延遲上升至超過某個阈值，該監控器會產生一個日志事件。
圖 9 顯示了篩選操作的定義。在此配置中，篩選操作已被定義，在本例中是 “Shape”。
應用哪條篩選規則的消息可以是選擇性的。您可以使用各種條件來確定用於篩選計算的消息的特征。例如，輸入消息的 URL、HTTP 標頭和 HTTP 方法可能是條件篩選的一部分。圖 10 顯示了一個示例，該示例只選擇 HTTP 方法是 POST 的那些消息。
查看本欄目
結合使用消息類型和篩選操作，生成計數或持續時間監控對象。在圖 11 的示例中，對 POST 類型的消息進行了計數。當它們超過 100 TPS（1000 毫秒的時間間隔）時，就會對消息進行 “調整” 或將它們放置到臨時隊列中，並以受控速率執行處理。阈值計算包括一個 “Burst Limit” 值。此值允許采用不均勻的事務速率，並包含一個計算，在該計算中，允許在連續的時間間隔中使用以前的時間間隔中 “未使用” 的計數。一般的最佳實踐是時間間隔至少為 1000 毫秒，並且突發率是速率限制的 2 倍。
服務水平監控（SLM）為事務分析提供更具選擇性的基礎，並提供結合 SLM 規則或者語句來開發復雜的監控流程的能力，從而擴展了計數和持續時間監控器。
SLM 被配置為 Multi-Protocol Gateways and Web Service 代理的處理策略內的一個處理操作。一個 SLM 操作指定一個 SLM 策略對象，每個對象由一個或多個 SLM 語句的有序序列組成。每個 SLM 語句定義了一組單獨的接受和實施標准，以及應采用的操作。SLM 策略提供了執行所有語句的選項，一直執行語句，直到采用了某個操作，或者一直執行語句，直到策略拒絕了消息。圖 12 顯示了一個已配置的 SLM 策略，其中包含一個 SLM 語句。
圖 12. 包含一個策略語句的 SLM 策略
查看本欄目
每個 SLM 語句都提供一些要配置的選項：
憑據和資源類：這些指定了用於選擇哪些傳入消息將被應用語句的條件。這可能包括來自身份驗證操作的用戶身份的詳細信息、事務性元數據（比如 URL 或傳輸標頭），或通過用戶編寫的 XSLT 提供的自定義信息。
時間表：這指定了何時應用語句的時間幀。這提供預配置事件（如下游應用程序維護或 “黑色星期五” 購物事件）的能力。
SLM 操作：這指定了在傳入的消息超過語句的阈值時應采用的操作，該操作通常是通知、調整或拒絕。這類似於計數和持續時間監控器操作。
阈值的時間間隔長度：這指定了以秒為單位測量的時間間隔長度。
阈值的時間間隔類型：這指定了時間間隔的計量方式。時間間隔可以是固定、移動或並發的。
阈值算法：這指定了對阈值時間間隔內傳入的消息進行計數的方式。通常情況下，會使用一個簡單的 “大於” 算法來設定事務速率上限。不過，也提供更復雜的算法，比如 “令牌桶”，這類似於 Monitor "Burst Rate" 計算。
阈值類型：這指定了傳入的消息應用於阈值時間間隔的方式，是通過計數，還是通過跟蹤延遲。
阈值水平：這指定了執行操作的觸發點。
圖 13 顯示了 SLM 語句表單。可以綜合使用多個 SLM 語句，以提供復雜的服務水平協議和節流過程。可以配置一組 SLM 語句，其中每一個語句都專為處理可導致內存或資源耗盡的特定情況而定制，這樣做可以更好地保護作為一個整體的設備免受客戶端、端服務和後端服務器中的異常情況的負面影響。SLM 設計戰略是，在有可能延長事務處理時間、導致要處理的事務積壓時，對傳入消息的流量進行限制，因為每個處理中的消息都會消耗設備資源。
以下各節將描述如何配置每個 SLM 選項來處理這些類型的情況。
有些時候，結合使用 SLM 和計數或持續時間臨控器可以提供最有效的事務控制。計數監控器不考慮事務的延遲。計數監控器始終使用速率算法，它只對傳入的請求進行計數。例如，如果監控器執行 10 TPS 的限制，但後端速度緩慢，需要 120 秒才完成，那麼設備上可能會同時有數千個活躍的事務。當使用大於或並發算法時，SLM 會考慮到延遲，因此 SLM 可以防止出現緩慢的後端。
最佳實踐是使用監控器作為總錄取控制算法，同時允許 SLM 處理更細粒度地管理資源詳細信息。
實質上，SLM 是一種轉換，在其處理過程中會使用一些資源。攻擊者可以利用並發連接淹沒設備，甚至在 SLM 計算開始之前，資源就已經很有限。計數監控器是輕量級的，因此它們可以處理連接洪水。
查看本欄目
現在，我們已經介紹了事務管理的一些基本組件，讓我們討論一些可以更好地調節事務流的簡單方法。我們介紹了監控器和 SLM 策略，還介紹了如何輕松利用這些戰略通過後端服務監控事務，以及如何使用它們來控制後端服務中的延遲。您還可以在與 “第三方” 服務交互的時候使用監控器和 SLM 策略。我們在簡介中提到 DataPower 可以與許多不同的端點進行交互，而且我們已經介紹了日志記錄服務，這是一個良好的示例。當日志記錄服務響應速度緩慢時，情況會怎樣呢？事務開始在 DataPower 中排隊，同時會消耗資源。所以，讓我們使用這些技術來控制這種情況。
我們不是通過結果操作直接訪問日志記錄服務，而是要創建一個 “門面服務”，我們將在該服務中應用監控功能。這提供了監控、調整或拒絕響應變得太慢的請求的能力。要封裝監控器，門面服務是必需的，因為結果操作本身不提供這種功能。如果您使用的是固件版本 5.0 或更高版本，也可以使用門面服務中已有的 “已調用規則（called rule）”。已調用規則包含本用例中的監控器。圖 14 顯示了我們的體系結構示例。
在同一設備上創建門面服務可以最大限度地減少網絡延遲。不過，門面服務也可以位於設備上的另一個域中。SLM 資源類應該是並發連接。這一點很重要。其他算法對於緩慢的後端都有潛在的漏洞。但是，並發連接沒有，因為它是即時計數器。
門面服務的前端處理器（FSH）是一個簡單的 HTTP 連接。在這種情況下，不要使用持久連接，原因有以下幾個：
首先，在環回接口，不使用持久連接就不會有資源或性能損失。
其次，當使用持久連接時，設備在每個事務結束後緩存一些內存，這會增加服務的開銷。因此，既然沒有任何好處，就不要使用持久連接。
圖 15 顯示了簡單的門面服務（或可能已調用規則）。同樣，我們正在做的是在到達日志記錄服務的路徑內封裝一個 SLM 策略。
查看本欄目
圖 16 演示了 SLM 策略，顯示了包含一條規則的策略，以及資源類（使用並發連接）、（拒絕消息的）節流操作的詳細信息。策略規則使用了 1 秒的固定時間間隔，“count all” 阈值為 20。也就是說，允許出現並發事務，但拒絕並發事務超過 20 個。
圖 17 顯示了主要處理策略的配置變化。在原來的規則中，事務直接轉到日志記錄服務；在第二個規則中，它們被發送到環回（127.0.0.1）接口上的門面服務。
圖 17. 使用門面服務之前和之後的策略規則
查看本欄目
就這麼簡單。現在，我們已經修改了配置，以便監控日志記錄服務事務。當它們過於緩慢時，我們就會拒絕整個事務。
綜上所述，使用門面服務的一些最佳實踐是：
後端可以是任何協議；在本例中，使用的是 HTTP 協議。
規則中的所有操作都必須是同步的。
響應消息的類型應該是直通的（未處理的）。
請求類型可能應該是非 XML（預處理的），以產生最小的開銷。
其他所有設置都應采用默認值。
如有需要，您可能還想探索流線化和流量控制。如果您使用異步操作發送大量數據，這非常有用。
請求規則應該有一個單一的操作，即 SLM。
操作的輸入和輸出應該是 NULL。
SLM 應該只有一個單獨的語句在使用並發連接資源。
該語句應該拒絕額外的事務。
在創建門面服務後，讓我們來看看它對服務資源利用率的影響。我們將通過一個服務處理事務，該服務直接訪問日志記錄服務，並使用門面作為一個網關，該門面使用了並發連接 SLM 策略。我們將使用內存狀態作為系統利用率的一項指標。
在第一次測試中，我們將使用 Apache Bench（這是一個免費的簡單工具），采用各種不同的並發率來處理一系列的事務。我們已經創建了一個具有內置延遲的日志記錄服務，以演示響應緩慢的服務。如圖 18 所示，當事務開始慢下來的時候，它們正在排隊並且會使用內存。
查看本欄目
在第二次測試中，我們將再次使用 Apache Bench 來處理一系列的事務。不過，在本例中，當日志記錄服務再次緩慢響應時，SLM 策略拒絕了事務，在 DataPower 中帶來的影響是資源消耗出現極大的變化。圖 19 顯示，空閒內存從未低於 95％。一般會通過日志記錄消息、警報或其他監控工具來通告事務被拒絕。收到 “第三方” 服務延遲警報的管理人員可以響應延遲問題。如果是系統性的問題（例如，“黑色星期五” 銷售高峰），可能會分配額外的 DataPower 資源來處理這些周期性的流量高峰。
在本文中，我們介紹了 DataPower 在政策實施和服務集成中往往占據中央位置。我們還介紹了與 “第三方” 服務的交互中的延遲如何影響該體系結構。如果不加管制，服務延遲可能對 DataPower 事務處理產生有害影響。DataPower 為資源監控提供了幾種方法，我們演示了在系統、域和服務中分析資源利用率的能力，並深入到處理政策內的具體操作。
我們介紹了一些基本事務管理選項（包括計數和持續時間監控器，以及服務水平管理），以及如何使用它們來調節和順暢事務流量，減少與 DataPower 交互的服務所暴露的延遲。我們還提到了通過 WSRR 提供的一些更高級的治理功能。
最後，我們演示了如何在特定用例中使用這些技術，在該用例中，集成服務（日志記錄服務）變得響應緩慢，我們還演示了如何使用門面服務技術提供了一個更靈活、更有效的 DataPower 實現。
