图 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，从而将性能优势扩展到更广泛的用例（包括那些只需在一个方向上签名或加密的用例）。