CXF 性能比较
Apache CXF Web 服务栈建立在与本系列早期文章讨论的 Apache Axis2 及 Metro 栈相同的一些技术的基础之上。与 Axis2 类似，它使用 Apache WSS4J WS-Security 实现。与 Metro 类似，它主要使用 JAX-WS 2.x Web 服务配置和 JAXB 2.x 数据绑定（甚至使用与 Metro 相同的 JAXB 实现，但两个栈的版本不同）。但是，除了这些公共组件之外，各栈之间的差异还包括它们的处理引擎和 WS-SecurityPolicy 配置处理。
本系列的早期文章比较了 Axis2 与 Metro 的性能，包括在不同 WS-Security 配置下的简单消息交换。在本文中，您将了解 CXF 与 Axis2 及 Metro 最新发行版之间的性能比较。
与之前介绍 Web 服务性能的文章 — “WS-Security 的大开销 ” 和 “比较 Metro 与 Axis2 性能 ” — 相同，本文将测量当客户机与服务器在单一系统中运行时执行特定请求序列所需的时间。这种方法将多次比较 Web 服务 处理 开销，因为它可以消除网络延时和计时造成的开销。假定客户机代码没有明显慢于服务器，因此这些数据可以表示实际服务器在高负荷下的性能。
本文还将使用与早期文章相同的测试应用程序，即一个地震数据检索服务。该服务所使用的数据库中包含全球范围多年以来内发生的超过 93,000 次地震的数据。服务请求将指定时间范围和坐标范围，而服务将返回范围内的所有地震。请参阅 “WS-Security 的大开销 ”，了解关于测试应用程序和示例请求/响应消息对的完整信息。
与之前的文章相同，我们将使用两组请求序列来进行性能测试。第一组使用 1,000 个请求，并调整查询参数以匹配整个地震数据库的小部分数据（在 1,000 个请求中，仅返回 816 个匹配的地震条目）。第二组使用 100 个请求，并通过调整使它匹配数据库中的较大部分内容（在 100 个请求中，返回 176,745 个匹配的地震条目）。这两个请求序列强调了 Web 服务栈的不同性能特性。第一个序列显示了栈使用少量数据处理请求的速度，而第二个序列则强调了处理数据量的速度。每个请求序列都使用不同的安全配置运行了 多次，结果中仅记录各配置表现最好的数据。
运行测试的硬件和软件条件是：Mandriva 2009.1 64 位 Linux 系统，Athlon X2 5400+ 处理器和 4GB 内存，使用 Sun (Oracle) Java 1.6.0_18 32-bit JVM（对于特定的堆大小来说，它的性能稍微好于 64 位）。服务器代码运行在 Tomcat 6.0.20 上，经配置将使用 1024MB 大小的堆，而客户机代码则使用 512MB 大小的堆。Web 服务栈版本如下：
- CXF 2.1.7
- Metro 2.0
- Axis2 1.5.1，以及 Rampart 1.5 发行版
如果您希望尝试在自己的机器和 JVM 上进行测试，那么请 下载代码 。
图 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 相当。
下图展示了以下安全配置的测试时间：
- 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.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，从而将性能优势扩展到更广泛的用例（包括那些只需在一个方向上签名或加密的用例）。
根据本文报告的测试时间，Metro 2.0 在基本请求/响应处理方面快于 Axis2 1.5.1 或 CXF 2.1.7。但是，在 WS-Security 处理方面，Metro 的 XWSS 库在总体性能上则无法与 Axis2 和 CXF 所使用的 WSS4J 库相提并论。
在这些结果中，最有趣的一点可能是 Axis2 影响。早期测试表明，Axis2 在 WS-Security 处理上要比 Metro 慢很多。这些测试结果表明，差异并非归因于 WS-Security 实现代码，因此必然与 Axis2（以及 Rampart 安全模块）处理传递给 WSS4J 以及从它接收到的消息的方式相关。这证实了 “比较 Metro 与 Axis2 性能 ” 中所讨论的结果。与其他栈相比，Axis2 运行测试所需的内存也要多很多，这在 signenecr 配置中尤为突出（Axis2 在客户机上大约需要 800MB 内存；而 CXF 只要 48MB 便足矣）。这些问题加强了 Axis2 浪费处理时间和内存来处理不同消息表示之间的不必要转换（WS-Security 处理的一部分）的早期印象。
接受测试的栈在使用 WS-Security 签名和加密方面的性能开销都很大。这种开销会对使用量较大的服务带来问题。在下一篇文章中，您将了解 WS-Trust 和 WS-SecureConversation 增件技术，该技术可以在客户机广泛使用特定服务时降低 WS-Security 开销。
| 本文的源代码 | j-jws14-src.zip | 4.86MB | HTTP |
原文：http://www.ibm.com/developerworks/cn/java/j-jws14/