Metro Web服务堆栈基于JAXB 2.x数据绑定和JAX-WS 2.x Web服务标准的参考实现,但是它使用其他组件来提供JAX-WS定义的基本支持之外的功能。 WS-Security和其他SOAP扩展技术由Web服务互操作性技术(WSIT)项目实现,而实际的WS-Security处理由另一个添加的组件:XML和WebServices安全项目(XWSS)实现。
Axis2基于完全不同的技术,包括默认的Axis2数据绑定(ADB)数据绑定实现,Axis2引擎本身以及与Java Web服务安全性(WSS4J)结合的WS-Security支持的Rampart模块。 本系列的较早文章“ (WS-)Security的高成本 ”展示了WS-Security处理对Axis2 Web服务堆栈中的性能的影响。
“ Metro简介 ”和“ Metro的 WS-Security ”向您展示了这两个堆栈在安装,配置和实际使用方面如何不同。 本文研究了两者之间的性能差异,包括使用WS-Security时的差异。
看表现
就像“ (WS-)安全性的高成本 ”一样,本文采用了一种方法,该方法测量客户端和服务器都在单个系统上运行时执行特定请求序列的时间。 这种方法在比较Web服务处理开销方面做得很好,因为从计时结果中消除了网络延迟和开销的影响。 假设客户端代码没有比服务器慢很多,这些数字也很好地表示了负载下服务器的实际性能。
本文使用与之前的文章相同的测试应用程序,即地震数据检索服务。 该服务使用的是一个实际数据库,该数据库包含了过去9年里全球发生的93,000多次地震。 对服务的请求指定了一个时间范围和一个地理坐标范围,并且该服务返回了指定范围内的所有地震。 有关完整的详细信息和示例请求-响应消息对,请参见“ (WS-)安全性的高成本 ”。
与上一篇文章一样,性能测试使用了两组请求序列。 第一组使用1,000个请求,并调整查询参数以匹配整个地震数据库的一小部分(对于1,000个请求,仅返回816个匹配的地震)。 第二组使用了100个请求,这些请求已进行调整以匹配数据库的较大部分(对于100个请求,返回176,745个匹配地震)。 每个请求序列在不同的安全配置中运行了多次,结果中仅保留了每种配置的最佳时间。
这些测试是在带有Athlon X2 5400+处理器和4 GB RAM的Mandriva 2009.1 64位Linux系统上运行的,使用Sun Java 1.6.0_13 32位JVM(对于64位JVM,它的性能要稍好一些)给定的堆大小)。 服务器代码在Tomcat 6.0.20上运行,配置为使用1024 MB的堆,而客户端代码使用512 MB的堆。 Web服务堆栈版本是Metro 1.5(包括WSIT和XWSS)和Axis2 1.5.1,具有当前版本的Rampart代码(因为仍然没有发布与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快了半秒。 在只有100个请求但响应较大的测试中,两个堆栈的运行速度相当快(不到0.1秒)。
图1.没有安全性的测试时间
这些计时结果表明(对于测试应用程序使用的数据)在每个请求处理中,Metro可能比Axis2稍快,但在实际数据转换中,两者并驾齐驱(当使用默认的ADB数据绑定与Axis2-其他数据绑定可能会给出不同的结果,尤其是XMLBeans绑定要慢得多)。
WS-Security的性能
下两个图显示了以下安全配置的相对测试时间:
- 普通 —无安全性(与图1中的值相同,但已标准化为Axis2时间)
- username-请求中的WS-Security纯文本
UsernameToken
- sign —带时间戳的正文和标头的WS-Security签名
- signencr —带有时间戳的主体和标头的WS-Security签名以及主体的加密
图2和图3都将测量的时间显示为Axis2纯时间的倍数,以便于比较结果。 图2显示了1,000个请求的响应时间很短:
图2.小响应测试
图3显示了具有大响应的100个请求的时间:
图3.大型响应测试
对于WS-Security配置,Metro始终比Axis2快得多–总体速度快两倍以上,对于大型消息,在用户名和签名配置的情况下,Metro快三倍以上。 对于两个具有相同成熟度的Web服务堆栈,这是令人惊讶的结果。
Rampart使用org.apache.rampart.TIME
记录器内置了基本的时间记录。 通过在DEBUG
级别启用此记录器,您可以找到Rampart处理各个部分所需的时钟时间。 奇怪的是,当我针对签名示例执行此操作时,我发现Rampart的处理时间不到测试总时间的一半。 这意味着Axis2 / Rampart WS-Security处理的主要性能问题位于Rampart和基础WSS4J安全实现之外。
Rampart当然有很大的改进空间。 正如“ (WS-)安全性的高成本 ”中提到的那样,只要涉及WS-Security处理,Rampart都会构建完整的消息内存模型。 在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的不同之处。
翻译自: https://www.ibm.com/developerworks/java/library/j-jws11/index.html