cxf 性能提升_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服务是Java技术在企业计算中的重要角色。 在本系列文章中，XML和Web服务顾问Dennis Sosnoski涵盖了对使用Web服务的Java开发人员很重要的主要框架和技术。 跟随该系列文章以了解该领域的最新进展，并了解如何使用它们来帮助您的编程项目。

看表现

就像前面有关Web服务性能的文章（“ （WS-）安全性的高成本 ”和“ Metro vs. Axis2性能 ”）一样，本文采用了一种方法来测量执行特定请求序列所需的时间，客户端和服务器在单个系统上运行。 这种方法在比较Web服务处理开销方面做得很好，因为它消除了定时结果带来的网络延迟和开销的影响。 假设客户端代码没有比服务器慢得多，这些数字也很好地表示了负载下服务器的实际性能。

本文还使用了与早期文章相同的测试应用程序，即地震数据检索服务。 该服务使用了一个数据库，该数据库包含了多年来在全球范围内发生的93,000多次地震。 对服务的请求指定了一个时间范围和一个地理坐标范围，并且该服务返回了指定范围内的所有地震。 有关测试应用程序和示例请求/响应消息对的完整详细信息，请参见“ （WS-）安全性的高成本 ”。

与前面的文章一样，性能测试使用了两组请求序列。 第一组使用调整了查询​​参数以匹配整个地震数据库的一小部分的1,000个请求（对于1,000个请求，仅返回816个匹配的地震）。 第二组使用调整后的100个请求以匹配数据库的较大部分（对于100个请求返回176,745个匹配地震）。 这两个请求序列强调了Web服务堆栈的不同性能特征。 第一个显示了如何以很少的数据堆叠处理请求的速度，第二个显示了处理数据量的速度。 每个请求序列在不同的安全配置中运行了多次，结果中仅保留了每种配置的最佳时间。

这些测试是在使用Athlon X2 5400+处理器和4GB RAM的Mandriva 2009.1 64位Linux系统上运行的，使用Sun（Oracle）Java 1.6.0_18 32位JVM（其性能比64位稍好）给定堆大小的JVM）。 服务器代码在Tomcat 6.0.20上运行，配置为使用1024MB的堆，而客户端代码使用512MB的堆。 Web服务堆栈版本为：

• CXF 2.1.7
• 地铁2.0
• 带有Rampart 1.5版本的Axis2 1.5.1

如果您想在自己的硬件和JVM上进行测试，请下载代码 。

没有WS-Security的性能

图1显示了在不使用任何WS-Security的情况下Axis2，Metro和CXF的测量测试时间。 从图表中可以看出，对于许多响应较小的请求，Metro显着快于Axis2和CXF（约快25％），对于较少响应的较大数量的请求，Metro的速度与Apache堆栈的速度相同。 （在本文的所有图表中，较短的条形会更好，因为它们表示速度更快。）

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

这些结果显示了与 Metro 1.5和Axis2 1.5.1的早期比较存在一些有趣的差异。 时序表明，至少对于测试应用程序使用的数据，Metro 2.0在按请求处理方面比Axis2和CXF更快。 在与XML的数据转换中，这三个堆栈的运行速度大致相同。 对于Metro和CXF，这是可以预期的，因为它们都使用JAXB参考实现进行转换。 从这些结果来看，默认情况下与Axis2一起使用的Axis2数据绑定框架（ADB）绑定实现的运行速度与JAXB差不多。

WS-Security的性能

下图显示了以下安全配置的测试时间：

• 普通 ：无安全性（与图1相同的值）
• username ：请求中的WS-Security纯文本UsernameToken
• sign ：带有时间戳的正文和标题的WS-Security签名
• signencr ：WS-Security对正文和标头进行签名，带有时间戳，并对正文进行加密

图2显示了对1000个请求的响应时间很小的测试时间：

图2.小响应时间

图3显示了相同的1,000个请求且响应较小的相对时间（根据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

这些测试时间反映了版本2.1.6和2.1.7之间CXF的显着性能改进。 代码调校是造成此问题的部分原因，但是改进的很大一部分是由于解决了“ 带有CXF的WS-Security ”中讨论的问题。 除非存在<sp:TransportBinding>策略或某种形式的加密或签名策略，否则CXF 2.1.6不会处理UsernameToken WS-SecurityPolicy配置。 通常，使用UsernameToken时会出现这样的添加策略，尤其是纯文本的UsernameToken因为无需传输级或消息级加密，就可以在传输过程中观察到用户名和密码。 但是从策略的角度来看，单独使用UsernameToken （如本文的用户名配置）是完全有效的，并且为CXF 2.1.7实现的修复程序可以解决这种情况。 作为修复的一部分，在这种特殊情况下，CXF 2.1.7跳过向响应消息流添加WS-Security处理的过程。

与使用CXF 2.1.6进行的相同测试相比，从用户名配置中的消息流中删除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的含义。 较早的测试表明，在WS-Security处理中，Axis2比Metro慢得多。 这些测试结果表明，差异不是由于WS-Security实现代码造成的，因此，这一定是由于Axis2（和Rampart安全性模块）处理往返于WSS4J的消息的方式所致。 这证实了“ Metro vs. Axis2性能 ”中讨论的结果。 Axis2还需要比其他堆栈多得多的内存来运行测试，尤其是对于signenecr配置（Axis2在客户端上需要大约80MB的内存； CXF可以运行48MB的内存）。 这些问题增强了先前的印象，即作为WS-Security处理的一部分，Axis2浪费了处理时间和内存，在不同的消息表示之间进行了不必要的转换。

对于所有测试的堆栈，使用WS-Security签名和加密的性能开销是相当大的。 对于开销大的服务，此开销可能会成为问题。 在下一篇文章中，您将了解WS-Trust和WS-SecureConversation附加技术，当客户端广泛使用特定服务时，它们可以减少WS-Security的开销。

---

翻译自: https://www.ibm.com/developerworks/java/library/j-jws14/index.html