Java Web服务的性能评价：从开发人员的角度外文翻译资料

 2022-10-25 11:24:19

英语原文共 7 页，剩余内容已隐藏，支付完成后下载完整资料

Java Web服务的性能评价：从开发人员的角度

摘要：

随着互联网的人口增长迅速，网络技术的发展就显得极为重要。对于Web2.0的演变，Web服务是必不可少的。Web服务是允许在网络上不同平台的计算机进行交互式通信，而不需要

人们阅读额外的接口和格式，例如网页的结构。由于Web服务是互联网的成长未来的趋势，开发的工具也很重要。虽然有许多Web服务框架的选择可供选择，开发者应该基于性能，时间和精力的框架，选择最适合自己的应用程序框架。在这个项目中，我们选择了四种常见的框架，从定性和定量指标对它们进行比较。运行测试后，结果进行统计采用SAS分析。

关键字：web服务，框架，java,开发者

  1. 介绍

当我们到其他州后者国家去旅行的时候，我们通常需要购买机票、租一辆车，预定酒店。当处理飞机票的时候，大多数的时候我们是买几张转乘飞机票而不是一张直达的飞机票来到达我们的目的地。这将花费我们大量的时间去查找飞机起飞和落地的时间。如果有几分钟就能把这所有的一切搞定呢？所以人们通常找代理商为他们做这些事情。但是这个代理实际上是虚拟的网上代理。如果一个人仅仅进入起点的位置，目的地、到达的时间，所有的信息都能进入电脑里面，电脑能立刻显示所有的结果给人们去选择和购票。甚至，这种虚拟的代理甚至可以显示目的地的汽车租赁和酒店信息，并且可以预定它们。通过这种虚拟的代理，可以节省大量的时间和精力，并且比人工代理还要准确。这种技术依赖于web服务的开发和广泛。

用大量开源的框架能使开发web服务程序变得容易许多，而不是从头开始开发web服务程序。

对于web服务的开发还有什么比这些框架更好的选择吗？在这次的研究通过做一些测试和分析来定性和定量来比较四种比较受欢迎的开源框架。这四种框架分别是 Apache Axis、JBossWS,、XFire、 and Hessian。在第二节里面有更多的关于web服务的介绍。第三节

描述了在本次研究中要使用的四种框架。在第四节里面，对用于测量所述的框架的指标进行了详细的说明。第五节里面介绍了对测量结果进行统计分析的方法。第六节显示和分析实验结果。第七节进行总结。

  1. web服务框架

因为web服务的设计是用来以常见的方式传输数据，一些公司和集团为了让开发人员方便开发，开发了一些web服务框架，使他们必从头开始编写一个完整的Web服务。一些流行的框架是 Apache Axis,、JBossWS,、Codehaus XFire,、和 Caucho Hessian。在这节里面，将会介绍这些框架。

2.1. Apache Axis

Apache Axis的（阿帕奇可扩展交互系统）是由Apache软件基金会（ASF）创建的一个开源、Java和基于XML的Web服务框架。该基金会是一个非营利性的公司，它主要生产的软件用于网络功能，如服务器，和用于服务器的框架。他们的项目是众所周知的协作、基于发展的共识过程，免费或者是开源软件。Apache Axis包实现SOAP服务器API的生成和部署web服务应用程序。SOAP引擎构造SOAP处理器像客户端，服务器和网关。这使得服务器和客户端通过SOAP进行通信。该API支持各种语言。除了java以外，还可以实现C 。

它允许开发人员以多种方式构建应用程序。最简单的方法只需要将文件的扩展名由“.java”改为”.jws”。这种方法的缺点是缺乏进一步配置的灵活性。

2.2. JBossWS

JBossWS是J2EE兼容的Web服务的JBoss的实现。该框架的设计更适合在整个JBoss框架,

通常更合适具体的J2EE对Web服务的要求。JBoss有自己的服务器，而不是用传统的Apache服务器框架，建议JBossWS这个框架用在自己的JBoss的服务器上以获得最佳的性能。与ASL相似，JBoss群是一组专注于开源项目的人。他们的项目强调Java企业级软件的开发，这些软件是连接操作系统和应用软件的桥梁。

2.3. Codehaus XFire

Codehaus XFire的是下一代的java SOAP框架。这是一个可以使您非常方便和简单实现Web服务的免费和开源框架的SOAP框架。它同样提供许多功能鉴定哪些web服务规范尚未在大多数的商业或者开源工具中使用。据称它是因为在模型的基础上建立了低内存的StAX（流API用于XML）而具有了更高的性能，但没有数据记录这个事实。

2.4. Hessian

Hessian的二进制Web服务协议，使开发Web服务简单实用而不需要大的框架，使开发人员并不需要花更多的时间和精力来学习协议的字母表。由于它是一个二进制协议，在发送二进制数据上它运作良好，无需带附件的扩展协议。因为Hessian是一个小协议，J2ME设备可以和手机、iPad 一样使用它更好的连接到web服务器上面。在Hessian麻布后Hessian被命名，这是英国对于粗麻布的表示。它以这种方式被命名，是因为粗麻布是简单、实用、有用的、但极其普通的材料，这就好比Hessian协议的特点。

  1. Evaluation Metrics

在比较不同的四个框架时考虑，需要不同的因素。一些指标来判断性能和效率，有些是显示透明性和抽象。本节将介绍这些指标。

3.1. Latency

在网络方面，延迟是它需要多少时间要发送回请求数据的表达式。这包括请求被发送到服务器的时间、服务器处理请求的时间、结果被送回的的时间。网络延迟受许多因素的影响，如传播，传输，调制解调器和路由器处理和存储延迟。传播是时间的对象，比如数据，就是从一个位置以光速传另一个播到位置。传播的延迟来自于像光纤或者无线网络这样的媒介。调制解调器和路由器需要时间来检查一个数据包的头部。存储的时间延迟实际来自于硬件存储,如硬盘存储接收到的数据。在这个项目中,测试不同情况的延迟，比如要求传输的数据为1、2、3、4、5 MB,1、5、10、15、20客户同时请求数据。从这些测试的结果,可以相比每一个框架并且找到他们的趋势。

3.2. 吞吐量

吞吐量是客户端或在特定时间单元内处理数据的的量，例如一秒钟。它和延迟高度相关，因为脚本的高延迟将导致吞吐量低，脚本的低延迟将导致吞吐量高。然而,通过查看延迟图,我们只能知道响应时间的趋势,虽然我们可以通过查看吞吐量图框架来确定最有效的情况。

3.3内存使用率情况

在计算机中，内存是暂时存储计算机的运算数据的存储器。有各种各样的内存,如缓存内存、闪存、随机存取存储器(RAM),虚拟内存等。无论哪一种内存，由于成本和空间，它们在服务器的数量被限制。一个框架,它使用更少的内存会让服务器有更高的能力的优势。

3.4 CPU使用率

中央处理单元(CPU),也被称为处理器,是计算机中一个用于解释程序指令和处理数据的组件。虽然它一次只能处理一个任务,当有多个任务要做时,不是完成一个任务然后接着完成另一个任务,相反地CPU被设计为如果有必要的话在完成当前任务之前可以切换到其他任务,这样感觉像是它同时执行多个任务。然而，大任务可能占用大量的CPU时间，从而降低原定于其他任务的时间。使用更少的CPU框架将使服务器有更多的时间来执行其他任务。

3.5 原代码行

在一个框架中使用的代码的源代码的行数（SLOC）可以指示框架的透明度和阻塞。一个框架的主要目的是为了节省开发人员的时间和精力而不需要从头开始编写整个代码。因此框架所需的代码行数越少,这个框架就更能节省时间和精力。然而,行代码不可能完全准确,因为有些行可能长有些可能短。所以文件的数量和文件大小的也是一个考虑的因素。

  1. 统计分析方法

在对检索的测试数据的性能进行比较后，我们需要一个方法来分析结果。通过计算简单的平均响应时间，使他们变成一个图表的分析是不够的。看着1.5秒和1.6秒的平均响应时间,我们不能确定这是一个很大的差别。因此,需要统计分析方法来判断差异是否显著。在这个项目里面，一般线性模型（GLM）[9]和双向方差分析（双向ANOVA）被用于统计分析。另外，统计分析系统（SAS）[10]作为一种工具用于帮助计算所需的统计分析。

4.1 SAS系统

SAS系统是有各种各样统计模块和程序的统计分析软件。他们使用第四代语言(4 GL)，用于由数据步骤,过程步骤,和宏语言三个主要部分组成的代码和程序。数据步骤是输入数据，如在代码中插入数据或者从数据文件中读取数据。过程步骤是使用的统计方法和模型来分析在数据步骤中被读取的数据。宏语言是用来减少冗余的功能在程序中反复使用。

4.2 GLM模型

GLM模型是在一般情况下使用的一种统计线性模型。它是许多统计分析的基础,如t检验、方差分析、协方差分析(ANCOVA),等等。了解GLM模型的工作原理的最简单的情况是两个变量的情况下。此分析的目的是利用一种方法来精确地描述在此图中的信息。使用GLM模型，我们试图找到一条最接近图所有的点的直线。此线将被写为：y= y = b0 b 1x e，其中y是在y轴变量，x是X轴变量，b0 为截距（y的值当x等于0）， b 1是直线的斜率，e是误差。通过求解b0 和 b 1，我们可以得到关于这一线性直线在图中所描述的点的信息。在有两个以上的变量的情况下，该公式可以扩展为： y =b0 b1x1 b2x2 b3x3 ... bnxn e,，其中n是的变量数目。解决这样的问题的机制是相同的。

  1. 结果和分析

为了从得到SAS分析最佳的结果，每一种情况要被测试二十次。因为有五个不同数量的客户对四个框架进行了测试，所以有二十不同的情况。为二十个不同的情况而添加20个测试时间会导致SAS计算400次数据。测量的响应时间为在调用web服务之前记录的时间与收到数据请求后记录的时间之间的差。

5.1. 结果

5.1.1. 客户端方案

为了在不同的情况测试四种不同的架构，Web服务应用程序创建发送的数据。基于客户端数量对四个框架性能进行测试的五种情况是1个客户端，5个客户端，10个客户端，15个客户端和20个客户端中每个客户端检索1MB数据的情况。记录每个框架在每种情况下的平均响应时间。结果如图1所示。通过计算吞吐量的结果,图2显示了每个情况和框架下的每秒的平均客户。图2显示了每个框架最有效的客户情况。Apache Axis在10个或者更多的客户的情况下可以每秒处理4.993个客户端。Resin Hessian 在相同的情况每秒中能处理4.807个客户端。JBossWS在每一个情况每秒中处理0.943个客户端。Codehaus XFire似乎在5个客户情况中能够最有效地工作,每秒处理2.892个客户端。

图1 不同客户端情况下的延迟

图2 不同客户端情况下的吞吐量

5.1.2. 数据量情况

在图3和4中，显示基于不同的数据量的五种情况下的吞吐量的结果和平均值。

图4显示了每一种框架最有效的数据量情况。当发送的数有2MB或者更多的时候所有的框架的性能达到最佳。Apache Axis平均每秒发送3.617MB数据、JbossWS平均每秒发送1.287MB数据、Codehaus Xfire 平均每秒发送1.241MB数据、ResinHessian平均每秒发送1.017MB数据。

从所有的图表来看，感觉像是Apache Axis在所有的情况中有最佳的性能，但是从进一步的分析来看应该是SAS。

    1. 分析

显而易见，响应的大多数时间主要取决于对框架的选择、传输数据的数量、从web服务端调度任务的客户端的数量。这三个因素对测试响应时间的结果很重要。但是在做进一步的分析之前，我们必须使用GLM模型去确保三个因素的相互作用是否也是重要的因素。如果相互作用的因素不重要，我们可以使用Tukey的方法去做一些多重比较，然后能直接看到在所有的情况下哪个框架拥有最好的性能和哪个框架的性能最差；如果相互作用的因素是重要的，接下来我们需要具体问题具体分析。

图3 不同数据量情况下的延迟

图4 不同数据量情况下的吞吐量

      1. 客户端情况

首先分析来自客户端情况的结果，我们使用SAS系统去看每个因素的重要性。

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[152001]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章