Java Web Services 效能大比拚：CXF vs Axis2 vs Metro (含 WS-Security) 基準測試報告

測試背景與方法

• 同樣地震資料查詢服務 (93,000 筆)，Tomcat 6 + Java 6 32-bit。
• 兩組負載：
  ① 1,000 請求 / 小回應 (816 筆) → 吞吐導向
  ② 100 請求 / 大回應 (176,745 筆) → 序列化/傳輸導向
• 四種安全配置：Plain、UsernameToken、Sign、SignEncr。
• 棧版本：CXF 2.1.7、Metro 2.0、Axis2 1.5.1/Rampart 1.5。

無安全基準

• 小回應：Metro 最快 (~25% 領先)；大回應：三棧持平。
• JAXB (Metro/CXF) 與 ADB (Axis2) 序列化速度相當。

WS-Security 效能結果

小回應 (1,000 請求) - 相對耗時 (CXF=1.0)

→ Metro 全配置最快 (~10-12% 勝 CXF)；Axis2 最慢 (~45-55% 慢於 CXF)。

大回應 (100 請求) - 相對耗時 (CXF=1.0)

→ CXF 反超 Metro (~10-15% 快)；Axis2 仍最慢 (~30-40% 慢)。

CXF 2.1.6 → 2.1.7 關鍵修復

• 2.1.6 無 <sp:TransportBinding> 或加密/簽名策略時，**忽略 UsernameToken 政策**，導致安全處理缺失。
• 2.1.7 修正：純 UsernameToken (無傳輸/訊息加密) 時，**跳過回應訊息流的 WS-Security 處理**，效能提升數個百分點。
• 未來版本將進一步依需求動態啟用請求/回應單向安全處理，擴大優勢。

Axis2 效能劣勢根因分析

• 非 WSS4J 實現問題 (三棧共用 WSS4J) → **Axis2/Rampart 訊息模型轉換開銷大**。
• AXIOM (Axis2 物件模型) ↔ DOM/SAAJ 多次轉換，CPU 與記憶體雙重浪費。
• SignEncr 客戶端 Heap 需 ~800MB (CXF 僅 48MB)，容器部署密度極低。
• 印證早期發現：Axis2 架構層面的不必要轉換是核心瓶頸。

選型建議矩陣

結語

CXF 2.1.7 在大訊息 WS-Security 場景確立領先；Metro 在小訊息高吞吐保持優勢；Axis2 因架構轉換開銷在安全處理上全面落後。對於新專案，**CXF 是綜合表現最均衡、設定最簡潔的選擇**；若極度追求小訊息吞吐且接受 Metro 設定風格，Metro 也是強有力競爭者。下一步關注：WS-SecureConversation 如何進一步降低安全開銷。