圖 1 顯示了 Axis2、Metro 和 CXF 未使用任何 WS-Security 時的測試時間。從圖中可以看出，當請求較多而響應較少時，Metro 的速度顯著快于 Axis2 和 CXF（大約快 25%）；而當請求較少，響應較多時，其速度與 Apache 棧相同。（在本文的所有圖中，較短的柱表示時間更短，速度更快，即性能越好。）

這些結果顯示了一些不同于 Metro 1.5 和 Axis2 1.5.1 之間的 早期比較 的有趣的差異。時間結果說明，至少對于測試應用程序所使用的數據來說，Metro 2.0 在單位請求處理方面快于 Axis2 和 CXF。在與 XML 之間的數據轉換方面，三個棧的運行速度基本相同。這是 Metro 和 CXF 的預期結果，因為它們都使用 JAXB 參考實現來進行轉換。從這些結果中可以判斷， Axis2 所使用的默認 Axis2 Databinding Framework (ADB) 綁定實現的運行速度與 JAXB 相當。

回頁首

使用 WS-Security 時的性能

下圖展示了以下安全配置的測試時間：

• plain：無安全（與 圖 1 中的值相同）
• username：針對請求的 WS-Security 純文本 UsernameToken
• sign：主體和頭部的 WS-Security 簽名，使用時間戳
• signencr：主體和頭部的 WS-Security 簽名，使用時間戳和主體加密

圖 2 展示了 1000 個請求而響應較少時的測定時間：

圖 3 顯示了同樣 1000 個請求但響應較少時的相對時間（已標準化為 CXF 結果）：

在本測試中的所有安全配置中，Axis2 始終是速度最慢的棧。Metro 始終是速度最快的，但 Metro 和 CXF 之間的性能差異將顯著小于 CXF 和 Axis2 之間的性能差異：在不同配置中，Metro 大約比 CXF 快 10%，而 Axis2 要比 CXF 慢一半還多。

圖 4 顯示了 100 個請求但響應較多時的測定測試時間：

圖 5 顯示了 100 個請求而響應較多時的相對時間（已標準化為 CXF 結果）：

在第二項測試中，Axis2 仍然慢于 Metro 和 CXF（仍然只有 CXF 的一半左右），并且 Metro 和 CXF 處理少量響應消息的速度則反過來了，CXF 的速度要快 15%。

CXF 2.1.7 與 2.1.6

這些測試結果反映了 CXF 在版本 2.1.6 和 2.1.7 之間的性能得到顯著改善。代碼調優對此功不可沒，但重要的是修復了 “通過 CXF 使用 WS-Security” 中所討論的問題。CXF 2.1.6 未處理 UsernameToken WS-SecurityPolicy 配置，除非存在一個 <sp:TransportBinding>策略或某種形式的加密或簽名策略。通常，使用 UsernameToken 時需要提供一個增加的策略 — 特別是純文本 UsernameToken，因為如果沒有傳輸級和消息級加密，則用戶名和密碼在傳遞過程中將是可見的。但是，從策略的角度來說，使用 UsernameToken 是絕對高效的（與本文的 username 配置相同），并且為 CXF 2.1.7 實現的修復將處理這個問題。作為修復的一部分，CXF 2.1.7 在這種特殊情況下將跳過將 WS-Security 處理添加到響應消息流中的步驟。

與 CXF 2.1.6 運行的相同測試相比，在 username 配置中刪除消息流中的 WS-Security 將 CXF 的總體性能提高了幾個百分比。遺憾的是，版本之間的這種改善有點失真。如果 usernaeme 測試用例使用傳輸級或消息加密，則響應消息流中將提供 WS-Security 處理，并造成該配置的 CXF 時間結果慢很多。但未來的 CXF 版本有希望擴展策略分析，這樣僅在需求時才會在請求或響應流中配置 WS-Security，從而將性能優勢擴展到更廣泛的用例（包括那些只需在一個方向上簽名或加密的用例）。