Java Web服务： CXF性能比较
转载：http://gocom.cc/knowledge/soa/standard/2386.html
Apache CXF Web服务栈建立在与本系列早期文章讨论的Apache Axis2及Metro栈相同的一些技术的基础之上。与Axis2类似，它使用 Apache WSS4J WS-Security 实现。与Metro类似，它主要使用 JAX-WS 2.x Web服务配置和JAXB 2.x数据绑定（甚至使用与Metro相同的JAXB实现，但两个栈的版本不同）。但是，除了这些公共组件之外，各栈之间的差异还包括它们的处理引擎和WS-SecurityPolicy配置处理。
在本文中，您将了解CXF与Axis2及Metro最新发行版之间的性能比较。
关于本系列Web 服务是Java技术在企业计算中的关键因素。在本系列文章中，XML和Web服务顾问Dennis Sosnoski将讨论对于使用Web服务的开发人员起到关键作用的主要框架和技术。请关注本 系列，了解该领域的最新发展以及如何使用它们来帮助您编写项目。
性能概述
与之前介绍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上进行测试，那么请下载代码。
无WS-Security的性能
图 1 显示了Axis2、Metro和CXF未使用任何WS-Security时的测试时间。从图中可以看出，当请求较多而响应较少时，Metro的速度显著快于Axis2和CXF（大约快 25%）；而当请求较少，响应较多时，其速度与Apache栈相同。（在本文的所有图中，较短的柱表示时间更短，速度更快，即性能越好。）
图 1. 无安全框架时的测试时间
这些结果显示了一些不同于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个请求而响应较少时的测定时间：
图 2. 响应较少时的测定时间
图 3 显示了同样1000个请求但响应较少时的相对时间（已标准化为CXF结果）：
图 3. 响应较少时的标准化时间
在本测试中的所有安全配置中，Axis2始终是速度最慢的栈。Metro始终是速度最快的，但Metro和CXF之间的性能差异将显著小于CXF和Axis2之间的性能差异：在不同配置中，Metro大约比CXF快10%，而Axis2要比CXF慢一半还多。
图 4 显示了100个请求但响应较多时的测定测试时间：
图 4. 响应较多时的测定时间
图 5 显示了100个请求而响应较多时的相对时间（已标准化为CXF结果）：
图 5. 响应较多时的标准化时间
在第二项测试中，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，从而将性能优势扩展到更广泛的用例（包括那些只需在一个方向上签名或加密的用例）。
结束语
根据本文报告的测试时间，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开销。
Apache CXF Web服务栈建立在与本系列早期文章讨论的Apache Axis2及Metro栈相同的一些技术的基础之上。与Axis2类似，它使用 Apache WSS4J WS-Security 实现。与Metro类似，它主要使用 JAX-WS 2.x Web服务配置和JAXB 2.x数据绑定（甚至使用与Metro相同的JAXB实现，但两个栈的版本不同）。但是，除了这些公共组件之外，各栈之间的差异还包括它们的处理引擎和WS-SecurityPolicy配置处理。
在本文中，您将了解CXF与Axis2及Metro最新发行版之间的性能比较。
关于本系列Web 服务是Java技术在企业计算中的关键因素。在本系列文章中，XML和Web服务顾问Dennis Sosnoski将讨论对于使用Web服务的开发人员起到关键作用的主要框架和技术。请关注本 系列，了解该领域的最新发展以及如何使用它们来帮助您编写项目。
性能概述
与之前介绍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上进行测试，那么请下载代码。
无WS-Security的性能
图 1 显示了Axis2、Metro和CXF未使用任何WS-Security时的测试时间。从图中可以看出，当请求较多而响应较少时，Metro的速度显著快于Axis2和CXF（大约快 25%）；而当请求较少，响应较多时，其速度与Apache栈相同。（在本文的所有图中，较短的柱表示时间更短，速度更快，即性能越好。）
图 1. 无安全框架时的测试时间
这些结果显示了一些不同于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个请求而响应较少时的测定时间：
图 2. 响应较少时的测定时间
图 3 显示了同样1000个请求但响应较少时的相对时间（已标准化为CXF结果）：
图 3. 响应较少时的标准化时间
在本测试中的所有安全配置中，Axis2始终是速度最慢的栈。Metro始终是速度最快的，但Metro和CXF之间的性能差异将显著小于CXF和Axis2之间的性能差异：在不同配置中，Metro大约比CXF快10%，而Axis2要比CXF慢一半还多。
图 4 显示了100个请求但响应较多时的测定测试时间：
图 4. 响应较多时的测定时间
图 5 显示了100个请求而响应较多时的相对时间（已标准化为CXF结果）：
图 5. 响应较多时的标准化时间
在第二项测试中，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，从而将性能优势扩展到更广泛的用例（包括那些只需在一个方向上签名或加密的用例）。
结束语
根据本文报告的测试时间，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开销。