比较 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

你可能感兴趣的:(jvm,Web,应用服务器,Security,网络应用)