比较 Metro 与 Axis2 性能

Metro Web 服务堆栈是基于 JAXB 2.x 数据绑定和 JAX-WS 2.x Web 服务标准的参考实现，但它使用额外的组件来提供由 JAX-WS 定义的基本支持以外的特性。WS-Security 与其他 SOAP 扩展技术由 Web Services Interoperability Technologies (WSIT) 项目实施，实际的 WS-Security 处理由另一个附加组件实现：XML and WebServices Security Project (XWSS)（见 参考资料 ）。

Axis2 基于完全不同的技术，包括默认的 Axis2 Data Binding (ADB) 数据绑定实现、Axis2 引擎本身，以及用于 WS-Security 支持、联合 Web Services Security for Java (WSS4J) 的 Rampart 模块。本系列较早的一篇文章 “WS-Security 的大开销 ” 介绍了 Axis2 Web 服务堆栈中 WS-Security 处理对性能的影响。

“Metro 简介 ” 与 “Metro 服务下的 WS-Security ” 向您展示了这两个堆栈在安装、配置以及实际使用上的区别。本文着眼于两者性能上的不同，包括使用 WS-Security 时的不同。

检查性能

和 “WS-Security 的大开销 ” 一文类似，本文采用以下方法：当客户端和服务器在一个单一系统上运行时，测量执行一个特殊请求序列所需的时间。这种方法在比较 Web 服务处理 开销上很有用，因为网络延迟的影响和开销可以从时间结果中排除。假设客户端代码不会比服务器缓慢很多，这个数据就是服务器在负载情况下的实际性能的最好表示。

本文采用和早前文章相同的测试应用程序：一个地震数据检索服务。这个服务采用一个实际的数据库，它包含在一段时间内在全世界发生的 93,000 多次地震的记录。该服务的请求指定一个时间范围和一个地理坐标范围，然后服务返回指定范围内的所有地震信息。参阅 “WS-Security 的大开销 ” 了解更多详细信息和一个请求-响应消息对示例。

正如之前的文章所述，有两组请求序列用于性能测试。第一组使用 1,000 条请求，通过调整过的查询参数来找到整个地震数据库中匹配的一小部分（对这 1,000 条请求仅返回 816 个匹配的地震）。第二组用 100 条请求进行调整，找到数据库中匹配的一大部分（对这 100 条请求返回 176,745 个匹配地震）。每个请求序列在不同的安全配置条件下进行多次运行，只有每个配置下最好的一次能够保存在结果中。

测试在配备 Athlon X2 5400+ 处理器和 4 GB 的 RAM 的 Mandriva 2009.1 64-bit Linux 系统中运行，使用一个 Sun Java 1.6.0_13 32-bit JVM （对于给定的堆大小，它比 64-bit JVM 有更好的性能）。服务器代码在 Tomcat 6.0.20 上运行，配置使用 1024 MB 的堆，而客户端代码使用 512 MB 的堆。Web 服务堆栈的版本是 Metro 1.5 （它包含有 WSIT 和 XWSS），以及有当前版本 Rampart 代码的 Axis2 1.5.1 （因为还没有和 Axis2 1.5.x 代码匹配的 Rampart 发布）。如果您想要在自己的硬件和 JVM 上尝试这个测试，请 下载 该代码。

早前的文章只检查 Axis2 的性能，包含纯文本、SSL 和各种 WS-Security/WS-SecureConversation 配置。本文使用一组更有限的配置，但直接对比各配置下 Axis2 和 Metro 的性能。

未使用 WS-Security 时的性能

图 1 显示了没有任何 WS-Security 使用时 Axis2 和 Metro 两者测量到的测试时间。该图表显示这两个堆栈之间只有微小差别。在有 1,000 条指令和较少响应的测试中，Metro 比 Axis2 快 0.5 秒。在有 100 条请求和较多响应的测试中，两个堆栈是一样快（在 0.1 秒内）。

图 1. 没有安全设置时的测试时间

这些时间结果显示（对测试应用程序所用的数据）Metro 在处理每条请求的时间上，可能比 Axis2 稍快，但是在实际数据会话时它们不相上下（当使用和 Axis2 绑定的默认 ADB 数据时 — 其他数据绑定可能有不同结果，特别是 XMLBeans 绑定，它要慢很多）。

使用 WS-Security 时的性能

随后的两组数据显示了遵循安全配置的相对测试时间：

• plain — 无安全性（和 图 1 中值相同，但针对 Axis2 的时间规范化）
• username — 在请求上的 WS-Security 纯文本 UsernameToken
• sign — 有时间戳的 WS-Security 头部和主体签名
• signencr — 有时间戳和主体加密的 WS-Security 主体和头部签名

图 2 和 图 3 以 Axis2 一般时间的倍数显示测量到的时间，方便比较结果。图 2 显示了有较少响应的 1,000 条请求的时间：

图 2. 较少响应测试

图 3 显示了有较多响应的 100 条请求的时间：

图 3. 较多响应测试

Metro 在 WS-Security 配置下要比 Axis2 快两倍，在大消息的 username 和 sign 配置下要快三倍以上。这对处于同一成熟度上的两 Web 服务堆栈是个惊人的结果。

Rampart 有使用 org.apache.rampart.TIME 日志程序的基本内置时间日志。通过在 DEBUG 级别启用这个日志程序，您会发现 Rampart 处理的各个部分所需的时钟时间。奇怪的是，当我对签名例子这么做时，我发现 Rampart 处理时间只占了测试所需总时间的不到一半。这表示 Axis2/Rampart WS-Security 处理的主要性能问题不在于 Rampart 和底层 WSS4J 安全的实现。

Rampart 肯定还有很多改进的空间。正如 “WS-Security 的大开销 ” 中提到的，Rampart 并没有在 WS-Security 参与进来的任何时候构建一个完整的消息内存模型（in-memory model）。构建内存模型的开销就是在 UsernameToken 例子中 Axis2/Rampart 表现不佳的明显原因。Axis2/Rampart 在其它 WS-Security 场景中表现不佳的原因也可能和这种类似的转换问题相关。

结束语

Metro 的独立使用配置可能比较古怪，特别是考虑到有限的文档可用性（见 参考资料 ）。 Metro 也只能与 JAXB 2.x 数据绑定和 JAX-WS 2.x Web 服务配置一起使用，和 Axis2 支持的更大范围数据绑定和替代配置刚好相反。但 Metro 对纯文本信息交换提供和 Axis2 一样的性能，在使用 WS-Security 时还有比 Axis2 更好的性能。如果您正在使用 WS-Security，并且关注性能，您应该考虑在您的应用程序中使用 Metro。

下一篇文章将转为介绍 CXF Web 服务堆栈 —— 另一个 Apache Foundation 项目。CXF 使用和 Axis2 相同的部分底层组件，但在配置和部署 Web 服务方面却截然不同。您将了解到 CXF 的基本用途，以及它和 Axis2、Metro 的区别。

原文：http://www.ibm.com/developerworks/cn/java/j-jws11/index.html