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

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

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

Sanjay Ahuja, Je-Loon Yang

美国佛罗里达州杰克逊维尔北佛罗里达计算大学

电子邮件：{sahuja，n00168553}@unf.edu

收到2010年3月7日;修订后的2010年7月2日;接受2010年7月3日

摘要 ：随着互联网的人口增长迅速，网络技术的发展就显得极为重要。对于Web2.0的演变，Web服务是必不可少的。 Web服务是程序，允许在网络上的不同平台的计算机，而不需要人的读接口和格式，例如网页结构额外的数据的交互式通信。由于Web服务是互联网的成长未来的趋势，用于开发的工具也很重要。虽然有许多Web服务框架可供选择，开发者应该选择基于性能，时间和精力的，最适合他们的应用程序的框架。在这个项目中，我们选择了四款共同框架，以定性和定量指标进行比较。运行测试后，结果进行统计采用SAS分析。

关键词：Web服务架构，性能，Java中，开发者。

1. 介绍

有关前往其他州或国家去，这个人通常需要购买飞机票，租一辆车，并接受预订的酒店入住。当处理飞机票时，大部分时间的人，甚至有买几票应对停止，而不是一票，会直接的到最终目的地。考虑飞机到达和离开时间来连接每一个航班可能需要搜索和规划的时间。如果有，能否可以做到这一切在短短的几秒钟虚拟代理？所以，通常人们会寻找做这个来代理他们。但是，如果这个代理实际上是一个虚拟代理上网。如果对方只是进入他想从目的地出发或到达所需要的时间，以及所有需要进入计算机的信息，在一个单元开始的位置，电脑显示所有结果供人们选择，并购买门票。更妙的是，这种虚拟代理有显示目的地的汽车租赁和酒店的信息，并保留它们可能性。通过使用这种类型的虚拟代理，可以节省大量的精力和时间，也可以比人类更准确。当然这种技术依赖于开发和广泛的Web服务。

相反，从头开始开发一个Web服务应用程序，有很多开源框架，使开发变得更加容易。其中这些框架将是Web服务应用程序开发一个更好的选择。这次研究通过做多次测试和分析从定性和定量比较四大流行的开源框架。这四个框架是Apache Axis, JBossWS, XFire, 和 Hessian。 Web服务更多介绍将在第二节完成.第三节描述了在本研究中使用的四种框架。在第4节，对用于测量所述框架的指标进行了更详细的解释。第五节引入的统计分析方法是用来分析测得的结果。在第6节显示试验结果示和分析。得出的结论是在第7节中。

1. 服务框架

由于Web服务设计为常见的方式传输数据，有几家公司和集团开发的Web服务开发人员方便使用的Web服务框架，使他们不必从头开始编写一个完整的Web服务。一些流行的框架是Apache Axis的，将JBossWS，Codehaus XFire的，和黑森州的Caucho。在本节中，这些框架将要介绍。

2.1Apache Axis

Apache Axis的（阿帕奇可扩展交互系统）是一个开源的，由Apache软件基金会创建的基于Java和XML Web服务框架（ASF）。该基金会是一个非营利性的公司，它主要生产用于网络功能的软件，如服务器，服务器和框架。他们的项目是众所周知的是合作性的，基于共识的发展过程和免费开源软件。Apache Axis的封装具有SOAP服务器的实现和用于生成和部署Web服务的应用程序的API。 SOAP引擎构造了SOAP处理器像客户端，服务器和网关。这使得服务器和客户端通过SOAP消息来进行通信。该API支持各种语言。除了Java版本，一个C 版本也是可以实现。它允许开发者在各种方法中应用。最简单的方法只需要从“.java”文件扩展名改变为“.jws”。这样的方法不利的一面是缺少进一步配置灵活性。

2.2. JBossWS

JBossWS是JBoss用于实现J2EE兼容的Web服务。该框架的设计更适合于整个JBoss架构，通常J2EE更合适Web服务的具体要求。而不是使用传统的Apache服务器这种框架的，JBoss有自己的一个服务器，并且建议用于在该服务器框架上以获得最佳的性能。类似ASF，JBoss的社区是一组专注于开源项目的人。他们的项目强调的是Java企业中间件，这是像应用程序，操作系统或两者之间的桥梁软件的开发。

2.3. Codehaus XFire

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

2.4. Hessian

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

3.评估标准

在这个项目中比较四个框架时，考虑不同的因素，一些指标，以确定性能和效率;有些是显示透明性和抽象性。本节介绍这些指标。

3.1. 潜伏

在网络方面，延迟是它需要多少时间来发送回请求数据的表达式。这包括对请求被发送到服务器，在服务器上处理该任务花费的时间，和结果被发送回的时间。网络延迟包含许多因素，如传播做出了贡献，传输，调制解调器和路由器处理和存储延迟。传播是它需要的对象，诸如数据，从一个位置中的光的速度传送到另一个的时间。传输距离如光纤或无线网络的介质的延迟。调制解调器和路由器需要时间来检查数据包的报头。存储延迟是花费的实际硬件存储器，如硬盘驱动器，用于存储所接收的数据的时间。在该项目中，等待时间与不同的场景，如请求1，2，3，4，和5 MB的数据，和1，5，10，15，20的客户端同时请求数据的测试。从这样的测试的结果趋势可以发现，并为每个框架进行比较。

3.2吞吐量

吞吐量是客户端或数据在特定时间单元内处理的量，例如一秒钟。这是高度相关的等待时间，由于高延迟的场景将导致低吞吐量，同样低延迟场景将导致高的吞吐量。然而，通过查看图的延迟，我们只能告诉响应时间的趋势，而我们可以通过查看吞吐量图确定的框架的最有效的方案。

3.3内存使用情况

在计算机中，存储器是存储临时数据以便计算的数据存储库。有各种各样的存储器，诸如高速缓冲存储器，快闪存储器，随机存取存储器（RAM），虚拟存储器等，它们都限定在服务器。使用较少的内存框架将有利于让服务器高容量的优势。

3.4 CPU使用率

中央处理单元（CPU），也被称为处理器，是在用于解释程序指令和处理数据的计算机的组件。虽然只是能够一次处理一个任务，当有工作要做多个任务，而不是在完成一个任务屎，如果需要的话，将同时采取行动，使它是在同一时间执行多个任务等。然而，大任务可能占用大量的CPU时间，从而降低原定于其他任务的时间。使用更少的CPU框架将允许服务器有更多的时间来执行其他任务。

3.5 源代码行

在一个框架中使用的代码的源极线（SLOC）可以指示框架的透明度和阻塞。框架的主要目标是通过不必从头开始编写整个代码，以节省开发者的时间和精力。因而所需的框架的代码少线，更多的时间和精力，由该框架保存。然而，行代码不可能完全准确，因为虽然有些行短一些有些行可能会很长。所以文件的文件的数量和尺寸也是一个考虑因素。

1. 统计分析方法

检索的测试数据进行比较性能后，我们需要一个方法来分析结果。通过简单地计算平均响应时间，使它们成为一个图是不够你分析的。看着时间1.5秒1.6秒平均响应，如果这是一个很大的差别与否，我们不能肯定。因此，需要的统计分析方法来告诉如果该差值显著与否。在该项目中，一般线性模型（GLM）[9]和双向方差分析（双向ANOVA）被用于统计分析。另外，统计分析系统（SAS）[10]被用作用于辅助所需的统计分析的计算工具。

4.1 SAS系统

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

4.2 GML模型

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

1. 结果和分析

为了得到从SAS分析最佳的结果，每一种情况下被测试二十次。由于有五个不同量的客户对四个框架进行了测试，有二十不同的情况。添加20个测试时间为二十个不同的情况下会导致由SAS计算400数据。除了客户端的量，数据的大小也被考虑。用五种不同的数据大小的送出，将有20例，总的400个数据集。响应时间通过记录时间权调用Web服务和记录被接收后的权利要求的数据，然后减去的时间差的时间测量的。

5.1结果

5.1.1 客户端方案

对于不同的场景测试四种不同的架构，Web服务应用程序发送出去的数据被创建。基于客户端的四个框架性能测试量的五种情景是1个客户端，5个客户，10个客户，15个客户和20个客户端检索每1MB的数据。平均响应时间为每个场景，每个框架被记录以供分析。结果示于图1，如图所示。通过计算结果可以通过，图2显示了平均每秒客户为每个方案和框架。

图1

图2

图2显示了每个框架的最有效的客户端方案。Apache Axis可以用10个以上客户到达的情景后来处理每秒4.993的客户。黑森州树脂可以处理每秒4.807客户那些相同的场景。JBossWS在每一个场景里处理每秒0.943的客户。Codehaus XFire在解决5个客户端情况下，处理约2.892用户每秒，看起来似乎是最有效的。

图3

5.12数据大小场景

作为结果和平均通过基于不同的数据大小的五个方案中，它们被示于图3和4。

图4

图4显示了每个框架的最有效的数据大小的方案。所有的框架在2 MB或更多的数据被发送后达到其最佳性能。Apache Axis有一个平均3.617 Mbps的，JBossWS的是1.287 Mbps，Codehaus XFire的有1.240，而树脂与黑森州为1.017。从上面的所有图表，它会看起来像Apache Axis的在所有情况下的最佳性能，但进一步的分析应该由SAS完成。

5.2分析

显然，响应时间量高度依赖于框架的选择，数据量的转移，以及从web服务调用任务的客户端的数量。这是响应时间显著使得这三个因素的试验结果。但在做进一步的分析之前，我们必须使用GLM模型，以确保如果三个因素的相互作用也是显著的因素。如果交互都没有，我们可以使用杜克的方法做多重比较，并直接看到它的框架在各种情况下具有更好的性能，并具有差;如果相互作用显著，我们不需要在通过案例结果的情况下进行分析。

5.2.1客户端方案

首先分析客户端方案的结果，从我们使用的SAS系统看各因素的重要性。事实证明，不仅是客户机的数量和框架显著因素选择，也是在它们之间的相互作用。这意味着，如果其中一个框架比其他一些在某些情形下显著更快，但不一定比那些在其他情况下的更快。因此说，不能在所有方案中直接比较所有框架。

在这种情况下使用普通线性模型（GLM）程序成对比较。在第一方案中第一框架相比于第二，比第一至第三，第一至第四，第2至第三，第二至第四和第三到第四位。所以就在每个场景中比较6次。

表1应的时间，即，当我们在寻找在1-客户端方案读取数据的情况下，我们忽略在5客户端，10的客户端，15的客户端，和20的客户端脚本中的数据。具有较低字母组具有较低的响应时间，这意味着更好的性能。在1客户端的情况下，所有的框架都投入团A，这意味着他们都在这种情况下拥有大致相同的性能。在5客户的情况下，将JBossWS放入B组，而其它的是在A组。这意味着在这种情况下，JBossWS比其他的性能差，而其他仍然有大约相同的性能。在过去的三个场景，Apache Axis和树脂黑森州比Codehaus XFire的更快，Codehaus XFire的比将JBossWS更快。

虽然从SAS分析结果框架的更好的性能是案件事项的情况下，由于客户数量的增加，性能比较的趋势是一样的，是Apache Axis和树脂黑森

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

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