《应用程序服务器与Web服务基准比较.docx》由会员分享，可在线阅读，更多相关《应用程序服务器与Web服务基准比较.docx（39页珍藏版）》请在课桌文档上搜索。
1、应用程序服务器与Web服务基准比较J2EE与.NET应用程序服务器与Web服务基准比较Middleware公司，2002年10月Middleware公司简介2002MiddIeWare公司目录表序言比较是公正的吗？修订过的JavaPetStore利用新的企业功能扩充PetStore改进的JavaPetStore应用程序改进后的.NETPetStore2.0新的实现的比较状态/高速缓冲存储数据的一个比较扩展的基准Web应用程序基准24小时分布式事务基准价格性能度量Web服务基准测试实验室与测试软件产品测试Microsoft.NET测试前.NET协调与优化配置需要的时间.,NET协调与优化配置.J
2、2EE测试前J2EE协调与优化配置需要的时间J2EE协调与优化配置Web应用程序基准测试测试方法24小时分布式基准Web服务基准Web服务基准直接Web服务请求WEB服务基准一远程SOAP客户端请求附录1代码行对比附录2Web应用程序基准的基准数据关闭图片下载吞吐量数据事务响应时间（秒）打开图片下载.吞吐量数据（每秒的图片与页面的数量）附录324小时分布式事务基准的基准数据附录4Web服务基准的基准数据来自于负载源的Web服务直接SOAP激活吞吐量（每秒的响应次数）响应时间（秒）Web服务远程SOAP客户端调用吞吐量（每秒的响应次数）响应时间（秒）附录5J2EE应用程序服务A的协调Web基准分
3、布式事务基准Web服务基准附录6J2EE应用程序服务器B的协调Web基准分布式事务基准Web服务基准附录7.NET1.0/WINDOWS2000服务器协调基本全局变量的修改：Web基准分布式事务基准Web服务基准附录8.NET1.1/WINDOWS.NET服务器2003协调基本全局配置的改变：Web基准分布式事务基准Web服务基准序言这篇报告包含了由MiddleWare公司得出的基于JaVaPetStOre最新实现的一系列广泛的新基准结果。这一新的实现在性能与伸缩性上都作了广泛的优化，测试是在两台先进的、市面上能够买得到的J2EE应用程序服务器上进行的。新的实现同时还扩展到支持两个物理数据库之
4、间分布式习惯XA事务。此外，实现中还增添了一项基于XML的Web服务与Web服务客户程序。为了基准的比较，MiCroSo丘也已经向MiddIeWare公司提供了相应功能的修订过的.NETPelShop2.0应用程序，该应用程序遵循相同的规范，同时MiddleWare已经完成了对它的审查工作。这个实现包含通过由COM+服务的.NET组件支持分布式事务；同时具有修订的J2EE实现中相应的Web服务功能。本文全面阐述两种新实现的性能与伸缩性广泛基准的比较结果。比较是公正的吗？ 难道J2EE版本不能够重新编写，对其进行优化以实现更好的性能？ 假如NET版本不使用贮存程序，而是使用与J2EE版本里相同的
5、动态SQL,那么其性能会发生什么变化呢？ 对比是否可信？尽管原始的比较使用的硬件是类似的，但并不是相同的，同时比较是由OraCle与MiCrOSoft各自的实验室完成的，使用的是不一致版本的MerCUryLoadRunner负载测试软件与不一致的测试台。修订过的JaVaPetStore熟知基于Web的J2EE应用程序服务器的MiddleWare公司，根据JaVa社区的反馈信息与企业开发者公布在TheSerVerSide上的反馈信息，使用J2EE与EJB从新创建了JaVaPe【Slore,对其性能进行了充分的优化，确保新的实现仅仅包含执行应用程序所需要的代码，而没有那些只是用来说明J2EE特征的
6、代码。同时MiddleWare公司将PelStore应用程序的功能扩展到支持重要的新的企业功能，这些功能包含分布式、习惯XA事务与基于XML的Web服务。这一新的应用程序已经被作为MiddleWare的JaVaPelStore2.0公布在TheSerVerSide上。同时MiCrOSOfl也将他们的.NETPetShop升级至J2.O版，增添了支持分布式事务与Web服务的功能，在.NET应用程序中使用所有的动态SQL来代替贮存程序。MiCrOSoft已经将这个新的.NETPetShop2.0版本公布在MSDN上，供.NET开发者在创建他们自己的n层Web应用程序的时候作为一个蓝图使用，同时Mi
7、CroSOft也在SerVerSide上公布了源代码。MiddIeWare公司在新的实现中完成了一系列广泛的基准，使用的是与应用程序服务器与数据库后端系统相同的硬件，同时使用了相同的测试台。本文包含了这些有MiddleWare公司执行同时验证的测试的结果。这些测试包含广泛的J2EE应用程序服务器协调与优化，都是在2002年6月至J9月的四个月的时间内进行的。MiddIeWare公司颁布的基准的基本规则包含：1 .J2EE与.NET实现在功能上务必100%的相同，在行为上没有任何的区别。2 .两个实现都务必是根据最佳实践代码准则创建的，这样现实中的消费者在创建他们自己的应用的时候能够遵循每一项有
8、效设计模式服务。3 .每一个应用程序在逻辑上都务必是三层实现，使用分割好的组件来封装中间层商业与数据访问逻辑。4 .应用程序务必设计得使它们都能够跨多中间层应用程序服务器群集来缩小。5 .基准务必与能够响应现实世界产品配置的现实的应用程序服务器与数据库配置设置一起运行。利用新的企业功能扩充PetStore.为了使新的基准更加易于充分懂得，J2EE与.NET中的PetStore2.0应用程序需要扩展重要的新的企业功能，其中包含：分布式事务。在原始的SUn的JaVaPelStore中，所有的数据库事务都发生在单个的数据库中，而在PelSlOre2.0基准中，关于每一条命令，都有一项分布式的事务在两
9、个不一致的物理数据库之间执行，命令信息放在一个数据库中，而存货统计在另外一个数据库中进行。假如事务中有任何一部分失败，那么整个事务就会再从头开始。创建这样的应用程序与基准的目的是对使用JTA事务服务的J2EEEJB与通过利用COM+事务的.NET服务处理的.NET事务的性能进行对比。Web服务。PelSIore2.0包含有一项以XML格式提供命令信息的Web服务，这些信息包含所有命令的全面内容与每一条特殊命令的排列项。Web服务在SoAPLl上工作。除了Web服务本身外，PelSIore2.0还包含一个用来调用Web服务在浏览器中显示结果的简单的客户程序包。改进的JaVaPetStOre应用程
10、序JavaPetStOre应用程序通过许多途径来改进增加其性能。修订后的应用程序仍然保持具有EJB基础的设计模式，类似由J2EE升级而成的可缩放n层企业应用程序。然而，许多性能上的改进对应用程序进行了完全的性能优化，下面将全面的介绍这些性能的优化。事务边界的改进：尽管大部分原始的PetStore应用程序遵循应用程序的标准访问模式,调用一个EJB会话，这样完成一个事务就需要调用所有需要的EJB实体。改进后这种方法并没有在所有的情况下连续，由于它会导致原始的实施中某些性能的退步。比如，在某一类别所包含的产品报表中，三种各包含有三列的产品需要九次事务才能完成，而不是一次。在改进后的MiddIeJav
11、aPetStore2.0中，所有的事务边界都被修改以最小化事务次数为EJB实体实现了一种Read-MOSuy模式：在原始的PelStOre中，所有的实体都是读写式。这种模式开发简单，但是效率低下，由于每一次操作都会导致读写数据库一次，即使是对静态数据的操作也是如此。为了减轻这个问题的影响，有些适当的实体块被以一种Read-MoSUy的模式重新实现。在这种模式中，EJB实体被分成两个部分：一部分为只读模式，其状态储存在事务边界中，另一部分为写模式；两部分实体都分享一个引用，这个引用指向代表它们的数据的通用数据结构。只读实体块界面包含有访问方法，而写实体块界面包含有改变方法；所有的数据库读的方法都
12、包含在只读模式日B中，比如ejbLoad(),所有的写数据库方法都包含在写模式EJB中，比如ejbStore().此外，在整个实体中添加了isModifkd()方法，该方法能够写入数据库这样所有不必要的数据库更新都能够避免。改进了数据库索引的使用：改进后在通常的搜索方面都能够使用索引，比如搜索产品的名字与样品ID。此外，原始PelSIOre的表格生成脚本中的一个要紧关键字被忽略了，而这个关键字往往使得全面目录的访问非常的慢。去掉多余的JNDl查找与调用初始化：每一个数据资源与EJB原参考都储存在应用程序服务器的JNDl服务中。在原始的PeISlOre中，每次在这些参考被使用的时候，系统都要找出
13、JNDI初始背景，然后在JNDl中查找相应的参考。两者都仅仅只需要做一次就能够了。代码的改变使得所有不必要的JNDl调用都省去了。动态类只有一次初始化：在PeIStore中使用的一种在编译的时候载入不知名的类的设计模式就是用来显示JaVa的灵活性的。它通过查找将要作为字符串使用的类的名字，使用forName()操作来为该类生成实例来完成。然而，进程的灵活性的代价就是执行上的高耗费。那些类的名字在编译时已经明白的情况下，程序将这一过程移除同时类的名字被编码。在其余的情况下，程序确保类的查找与确定只执行一次，然后只有在此类生成新的实例的时候再次执行。就像前面提到的一样，还有许多其他的改进：包含广泛
14、的使用JDBC预定义的语句，对字符串处理的重大改变与其它的重大改进。然而，上面全面列出的这些改变带了了性能上的最大的改观。基于J2EE应用程序服务器A比较性的性能数据，与SUn公司最初实施的JaVaPetStOre相比，这些优化大致对性能提高了17倍。这一数据是根据对进行性能平衡(对分布式事务的支持，数据的高速缓存)后原始SUnJavaPetSlOre与新的MiddIeWareJ2EEPelStore2.0的比较得出的。新的实施与旧的实施相比，性能上的提高见下表：图L原始的SimJavaPetStOre与优化后的EJBJavaPetStore2.0峰值吞吐量的比较PeakThroughput4
15、x550MHzCPUApplicationServer改进后的.NETPetStore2.0与JaVaPetSIOre类似，.NETPetShop2.0的体系结构是由MiCroSofl推出的3层逻辑结构，其目的是为了创建基于NET的可缩放的企业应用程序。然而，在某些关键的地方，代码基础已经作了最新的改进，同时做了性能上的提高。最要紧的改变包含：1 .关于所有的数据库访问，使用动态SQL代替贮存程序。这样就消除了关于性能的提高是通过加入编译过的贮存程序，牺牲了数据库的轻便实现的争论。2 .在命令布置中使用了分布式事务。3 .使用一种基于SoAP的Web服务来返回命令的全面信息与调用客户页面。4
16、.使用数据转发器操纵代替数据栅格操纵来提高性能。5 .使用简单的数据高速缓冲存储器在中间层数据缓冲存储器中缓冲静态只读产品信息。新的实现的比较改进后的JaVaPetStOre实现仍然保持忠实于SUn微系统公布的MOdeI-VieW-COn【roller体系结构，充分利用包含会话块与实体块的J2EE核心特征的优势。在对软件进行上面全面列出的为优化性能而做出的广泛修改的同时，软件方面由SUn微系统推荐的基本设计模式与广泛应用的面向对象的开发方式仍然保持完整无缺。这一体系结构使得用户界面与中间层商业逻辑与数据访问逻辑完全分离，后端进程被封装在不一致的EJB中。类似的，.NETPelShop2.0也使
17、用了完全面向对象的n层体系结构，为中间层与数据访问目标实施了C#类。这样它就实现了通过使用ASP.NETWeb表单将Ul与中间层商业逻辑完全的分开，而ASP.NETWeb表单则通过使用一种Code-behind模式（服务器端的代码通过封装与客户端HTML分开）将HTML与客户端单元与服务器端进程单元完全分开。Web表单模式利用了框架中提供的ASP.NET服务器操纵的优势，为大部分的UI/外观单元服务，比如列表，网格等。反过来，服务器操纵激活用C#语言书写的封装在单独的.NET集合（封装的、可重复使用的组件）中的中间层对象,这些中间层间接的通过封装在数据访问逻辑中的单独的一套数据库访问类在访问数
18、据库。状态/高速缓冲存储数据的一个比较为了使得呈现在用户面前的数据库信息尽量是最新的，务必确保两种实现有相同的行为。基本上来说，核心静态产品数据通常每24小时从数据库更新一次（尽管搜索仍然会查询数据库关键字来确定高速缓冲存储器中的什么记录需要显示,但是要紧是在运行测试的时候在中间层高速缓冲存储器查找），而消费者数据与用户目录却需要在每一位用户登录的时候都访问数据库，同时从数据库中更新帐单信息，这也是结帐过程的一部分。此外，所有产品全面目录的数量务必精确响应所有显示这些信息的应用程序页面更新后的数据库信息。JaVa版使用实体块来维持状态数据库信息；而.NET版使用.NET中间层高速缓冲存储器来储
19、存静态（只读）产品信息，高速缓冲存储器每24小时更新一次。考虑到数据的过时，这种配置在产品间具有相同的欣慰。在这一基准中，尽管.NET与J2EE应用程序服务器都被测试出支持页面输出高速缓存，但是动态页面输出缓存并没有使用。这样的决策的目的是强调中间层应用程序逻辑处理的性能。扩展的基准这一基准包含有三套单独的测试，这些测试能够为两个应用程序.NET与J2EE性能与缩放性特征提供一个公平全面的概括。这三套基准包含：1. Web应用程序基准2. 24小时基准分布式事务基准3. Web服务基准Web应用程序基准这一基准联系应用程序大部分的基本功能，在使用OraCle与MiCrOSofl的测试中，两个应
20、用程序的工作量相似，但并不相同。测试的目的是得到应用程序在低用户负载量到高用户负载量的过程中吞吐量曲线与测量响应时间，不给两种产品施压以测定他们分别在2个、4个与8个CUP应用程序服务器的配置下能够支持的用户数量的极限。测试脚本在有10秒缓冲时间的情况下执行（在OraCle的原始基准中，使用了20秒的缓冲时间，这就意味着与新的基准相比，在相同用户负载量的情况下，服务器所承受的压力只有一半）。页面输出高速缓冲存储也被停止，这样保证服务器务必处理收到的每一条请求。不一致用户负载量下的数据点都被单独的测量，同时测量ramp-up、settledown数据收集与rampdown时间来测定结果的精确性（
21、每一个单独数据点的总执行时间都超过1小时）。为了得到更多的信息，这套基准以两种不一致的方式执行：a.关闭图片下载：这样只有基本应用程序服务器引擎被使用到。这一测试能够显示产品操作包含服务器端脚本、会话状态管理、对象激活与数据库连通性在内的应用程序逻辑的良好程度。b.打开图片下载：模拟一个浏览器高速缓冲存储器这样，每个访问站点的用户在一次脚本重复期内都需要下载每一张单独的图片一次。这一测试能够显示应用程序服务器作为Web服务器/应用程序服务器的综合工作的合适程度。注意,这一基准的结果不能与过去OraCIeandMiCroSofi公布的PeIShoP的基准数据比较,由于使用了不一致的测试脚本与缓冲
22、时间,同时在应用程序的某些功能方面也与原始的PetShOP基准有差别。24小时分布式事务基准设计这一基准的目的是为了对每一个测试产品的分布式事务执行能力进行测试。测试脚本包含用户登录、然后单独的处理一条100条项目的命令。命令中每一条项目结帐过程的完成包含这个过程的最后一步就是用来激活一次分布式事务的命令的实际布置,脚本的最后是退出。每一个用户在一个用户会话中都会完成100次单独的分布式事务。测试会在每一个产品能够产生峰值吞吐量的用户负载下运行，同时持续24小时来观察这种吞吐量是否可持续。价格性能度量除了绝对性能度量外，每个产品基于4-CPU配置在24小时的运行中的价格度量也被计算出来了。这一
23、度量是以每次事务每秒花费的美元数来计算的。花费包含中间层的硬件的开销、应用程序服务器软件许可证开销（以4-CPU配置的每个产品的公布价格来计算）再加上用于应用程序服务器的操作系统的购买价格。价格度量中没有包含数据库许可证费与接下来的支持保护费用。Web服务基准这一基准测量为J2EE与.NET服务的Web服务的性能特征。测试包含两个基本的配置：a.Web服务的直接激活使用I（X）台分布式的物理计算机，每一台模拟多用户生成直接SoAP调用来激活Web服务。这一基准测试应用程序服务器处理SoAP请求的能力与作为Web服务提供者的能力。测试实验室与测试软件由MerCUry交互式代表在实验室里安装与配置
24、MereUryLoadRunner7.50测试是在大规模的实验室里进行的，这种实验室包含有100台客户端计算机，能够在保证客户端在系统中不成为瓶颈的同时产生高同步性的用户负载。实验室使用ClSCO吉比特主干线，每台服务器配置两个吉比特网卡，每一个网卡包含50个客户端子集。这样配置的目的是为了保证在测试的过程中Web不可能成为瓶颈。在吉比特Web中同时还配置了两台单独的数据库服务器。应用程序服务器测试在COmPaqProLiam8500服务器上运行，分别配有2、4、8个8550MHZ的CUP与2GB的RAM（对2CPU与4CPU设置）与4GB的RAM（对8CPU设置）。两个数据库也是COmPaq
25、ProLiam8500服务器，每台服务器使用8550MHZ的CPU与3GB的RAM,同时增加了光纤光学操纵器来加速COmPaqRAlD存储队列。数据库、客户端与Web利用在测试过程中都被监控以保证这些设备不可能成为瓶颈。在所有的J2EE与.NET的实例中，测试会精确的报告用于应用程序测试的应用程序服务器软件本身的能力。图2.基础Web应用程序基准、24小时分布式事务基准与Web服务直接SOAP激活基准测试的实验室布置。图3.带有在应用程序服务器之间远程SoAP调用的远程/代理Mib服务基准测试的实验室布置产品测试Microsoft.NET关于.NET产品，MiddIeWare公司测量的是其商业
26、公布的运行在WindOWS2000下的.NETFramework1.0(SP2)与在WindoWs.NETSever2003的RCBuild3681上创建4322.508的.NETFramework1.1RC。在测试中作为后端使用的是MiCrOSofISQL服务器2000数据库。.NET1.0and.NET1.1在配置上的精确优化在附录7.8中给出。测试前.NET协调与优化配置需要的时间.在开发出.NETPetShop2.0后（这个应用程序实际上是由一家设立在CalifOrnia的MiCroSOft解决方案提供者开发成功的），一个MierOSOft员工花了大约2个星期的时间试运行，在Middl
27、eWare公司测试前（单人2周的工作量）对程序进行包含配置设置方面的优化。NET协调与优化配置.优化就是在.NETFramework设置的基础上作些微小的变化。优化包含：1 .确保数据库正确的协调，拥有足够的存储空间来为小时事务的繁重运载量分配存储空间。2 .对基础ASP.NET设置作了修改，使得表单认证能够与基于WindOWS的认证对比，由于应用程序本身是一个能够通过任何拥有标准窗口的客户端平台访问的稀少客户应用程序（认证是以一个记录有用户名与密码的数据库为基础的）。3 .将ASP.NET工作器与IO线程从25个（WindoWS2000的缺省设置）下调到20个；微小的上调在Web服务运行期间
28、每一个客户端IP被同意的Web连接的数量来保证服务器同意每个负载生成客户端能够激活足够多的向.NET应用程序服务器的同步Web连接。4 .在WindoWS2000的测试中，设置ASP.NET进程模式以便.NET应用程序能够运行在与IISWeb服务器一样的进程空间。6 .在WindOWS.NET服务器下，两个工作器进程能够在4CPU与8CPU系统的HS服务管理中运行。ASP.NET工作器进程由WindoWS.NET服务器的ASP.NET自动的产生与监督，类似于利用J2EE应用程序运行应用程序服务器复制的概念。J2EE关于J2EE产品，使用两种领先的J2EE应用程序服务器来实施测试，在这篇报告中，
29、我们用J2EE应用程序服务器A与J2EE应用程序服务器B来分别表示。由于授权限制，因此MiddIeWare不能够透露被测试的J2EE应用程序服务器的名字。然而，选择的测试的产品代表了目前广泛使用的、在市场上能够自由购买到的企业J2EE应用程序服务器。J2EE应用程序服务器的测试使用OraCle9i后端数据库，由于这种数据库是每种产品首推使用的数据库，拥有完整的J2EEJDBC应用程序服务器特征的支持。两个应用程序服务器都在RedHalLinux7.2与WindOWS2000AdvancedSerVer（SP2）进行了测试。MiddleWare对两个应用程序在不一致的操作系统下运行作了比较,最后
30、使用能够为应用程序服务器提供最佳性能的操作系统的测试结果来公布。关于J2EE应用程序服务器A来说，使用WindOWS2000操作系统由于在该系统下这个应用程序服务器的性能明显的好于在LinUX7.2操作系统下；而关于J2EE应用程序服务器B来说，在WindOWS2000与LinUX7.2系统下性能相似，但是测试中还是选择了WindoWS2000要紧是由于在这一系统下更容易监督计算机在有负载的情况下的性能特征,而不必再使用嵌入的WindoWS2000性能监督器以至影响其性能。J2EE应用程序服务器A与J2EE应用程序服务器B精确配置优化在附录5-6中给出。测试前J2EE协调与优化配置需要的时间.
31、在J2EE优化后的应用程序开发成功后，两个有经验的MiddleWare公司的员工（全天）在进行最后的数据点测量前（单人10周的工作量），花了将近5个星期的时间为J2EE应用程序服务器A协调与优化配置。同时还花了将近5个星期的时间为J2EE应用程序服务器B（单人10周的工作量）协调与优化配置。对两台J2EE应用程序服务器的调整与优化配置过程是非常重要的，下面将会全面的讲解。J2EE协调与优化配置J2EE应用程序由MiddIeWare专家根据最有经验的销售者的指导对测试的不一致的应用程序服务器产品分别作了广泛的协调。协调包含用不一致的JaVaRuntimeEnvironment（JRE）与数据库驱
32、动程序检测产品以得到最优组合；与基本应用程序服务器设置优化，比如堆阵规模、高速缓冲存储块与线程设置。在对两个应用程序服务器的协调过程中，首先考虑到的是将要使用的JaVaRuntimeEnVirOnmem（JRE）与JDBC驱动器的选择。这里，一共测试了四种JRE：SunSoft1.3与1.4、JRockii3.1与IBM1.3。关于应用程序服务器A来说，SunSoft1.4是最快的，在基准中能够比SUnSOfl1.3产生多出50%的吞吐量。然而，由于SUnSoft1.4的兼容性问题，它能够用于Web应用程序与分布式事务基准，却不能够用于J2EE应用程序服务器A来做Web服务测试，因此在这里选择
33、了JRockitJREo这些JRE性能的一个重要的因素就是并发的碎片收集实现。假如这个特征不能够实现，那么由于碎片收集导致的暂停就会变的多余同时会导致在高负载量时发生“拒绝连接”的错误，由于应用程序服务器进程在碎片收集的过程中会停止工作。由于比SUnSOftJVM1.3相比提供更加优化的碎片收集的SUnSOflJVM1.4与产品一起工作（在Web服务测试中例外），J2EE应用程序服务器A会从中受益。然而J2EE应用程序服务器B不与SUnSoflJVM1.4兼容，因此，只能够使用SImSOfIJVM1.3。这个JVM能够为J2EE应用程序服务器B提供最佳的优化性能，尽管与SUnSOfiJVM1.
34、4相比，碎片收集仍然存在缺陷。结果发现，应用程序服务器B通过使用应用程序服务器的前后Web服务（一个单独运行的进程）来调节引入到应用程序服务器本身的请求能够获得更可靠的性能。这是由销售者B为他们的应用程序服务器推荐的实际经验。通过适当的调节引入到应用程序服务器的并发请求的数目能够使得服务器在相同的负载情况下运行更加快速与可靠，同时也能够把碎片收集的影响最小化。使用应用程序服务器的Web服务器的确是需要配置与调整来达到最优化的设置。Web服务器关键的配置变更是指现在在一个设置中，这个设置限定Web服务器与应用程序服务器启动是并发的连接与线程的数量。这个设置被设置得相对比较低（50个线程），以保证
35、对引入Web服务器的请求排队，同时保证应用程序服务器引擎中的队列十分小。设置的调节务必与应用程序服务器本身线程的调节一致，而这一过程是相当复杂的。但是最终这个设置能够保证应用程序服务器引擎本身在大量的请求压力下永远也不可能瘫痪，这样就会运行得更加可靠。假如Web服务器的配置同意太多的用户同时连接，那么吞吐量将随着应用程序服务器的不稳固而显著下降。即使是通过了这样的大量的调节后，在Web应用与分布式事务基准中，J2EE应用程序服务器B性能仍然不能像J2EE应用程序服务器那么好。与JTA分布式事务协作（这一特性在两个基准的测试中都被激活）性能差是一个要紧的因素，这就需要使用1.3JRE代替1.4J
36、RE。JDBC驱动器的选择需要基于下列标准：I特性的有用性：对事务的支持与可滚动的结果设置整体性能一共测试了四种驱动器：数据库提供者的驱动器（OraCle）、应用程序服务器提供者的驱动器与两个领先的第三方驱动器提供者。在排除掉那些没有必备特征的驱动器后，剩下的驱动器在负载下作了性能与稳固性测试。在决定使用JRE与JDBC驱动器后，应用程序服务器同时作了应用程序服务器参数与JaVa运行时间参数协调。除了协调额外的服务器实例外，通过在应用程序服务器引擎上运行多个服务器进程使得性能得到了很大的提高,应用程序服务器引擎使用DNS在服务器实例间平衡负载。这种配置对两个应用程序服务器的大部分都是最理想的，
37、由于它同意使用服务器上所有的内存，然而，每一个兼容产品务必单独使用更少的内存用于碎片收集，这就意味着周期性的碎片收集将会更加快速，减少进程相应的暂停时间。Web应用程序基准测试该平台包含两个脚木，比重各占一半，一个脚本用以模拟用户简单的浏览网址，另一个则模拟从网站寻找与购物。在只有浏览功能的脚本中，用户需要如下操作：1 .登录网站主页；2 .对IoOO种产品进行三次任意的文字查询，在每次查询结果的网页上，单击“下一步”按钮；3 .在某种范围内检验产品，重复三次；4 .对某种产品具体内容检验三次（包含产品存货纪录的实时读取）；关于具有浏览与查询功能的脚本，模拟用户需要：5 .对IoOO种产品进行
38、两次任意的文字查询，在每次查询结果的网页上，单击“下一步”按钮；6 .利用100,（X）O个用户中的任意ID,在网站注册；7 .在购物车中添加50000个中的两个项目；8 .检验，确认账户信息，然后根据购物车中的项目下订单；9 .有一半时间用户用于退出操作，而一半时间不是这样，因此，50%的活动被关闭，同时放弃这50%时间使得应用程序服务器能够处理关闭操作，关闭时间设定为10分钟，即假如10分钟内没有任何操作，则关闭之。这种做法是真正的电子商务网站对现实活动的合理模拟。10 .购物完成后，执行最后一次文字检索。测试方法对每种产品进行测试都包含两个完全独立的方法，一种是关闭图像下载功能，另一种是
39、开通图像下载功能（客户端具有浏览器缓存）。这么做是为了更全面的熟悉应用程序服务器性能，该性能包含两个方面，一个是终端处理情景，应用程序服务器本身不为PetStore站点图像提供服务；另一个是通常情况处理情景，应用程序服务器处理程序逻辑，同时提供下载图片到浏览器的功能。注意，.NETPetShop与MiddlewareJ2EEPetStore在其运行过程中使用不一致的图像。因此，就图像而言，.NETPetShop务必加以修正，才能打开J2EEP&Store图片，这样每种测试产品的图像数量与图像尺寸就相同了。另外，利用模拟浏览器缓存下载图片时，程序设置已经被固定，因此在用户不断使用过程中，对每个用
40、户而言，同一图片只能被下载一次，这类似于浏览器缓存确保图片因速度原因而在客户端存储的实际设置。因此，网页中的普通图片，比如导航条，每个用户只能下载一次，即便他作为一个模拟用户在脚本执行过程中访问多张网页。但是每个模拟用户的浏览器缓存都是事先固定的，因而他们务必各自重定义自己的图像缓存。这些测试是在2个，4个与8个CPU配置上运行的，目的在于熟悉当系统增加CPU时应用程序服务器功能的垂直变化。关于每个数据点，其数据运行由数据激增，平稳，数据收集与数据量减小这几个部分构成。从每个数据运行一小时的综合结果来看，只有当系统达到稳固状态时才开始数据收集。对单个产品而言，直到用户登录的响应时间达到3秒或者
41、者更大的时候，数据点才被获取，由于每个产品假如在这些用户登录数以上进行测试通常出错。因此那些功能扩展到承受更大用户量的产品才能够收集更多数据点。Web应用程序结果（关闭图片下载功能）图6：双CPU应用程序服务器的吞吐量曲线图7：4CPU应用程序服务器的吞吐量曲线TMQughpkdrMti(ideAoMef)4CRJAppicMen川图8：8CPU应用程序服务器的吞吐量曲线Web应用程序结果（启动图片下载功能）图9：吞吐量峰值图10：网页平均响应时间为3秒时的最大支持用户数WebApplicationBenchmark(imagedownloadon)MaximumSupportedUsers1
42、4000J2EE ApPiEkn J2EE AppMcatbn NET 1 0W2KNETSerer AServer B1 IAMndows NETO2CPU 4CPU 8CPU图11：2CPU应用程序服务器的吞吐量曲线图13：8CPU应用程序服务器的吞吐量曲线24小时分布式基准设计分布式处理平台的脚本是为了全面测试服务器处理大量分布式处理登录的能力，本文的测试对象则是编写命令。该脚本利用模拟用户进行如下操作：1 .从10万个有效用户名中任选一个，填写资料登录网站；2 .从5万个项目任选一个加入购物车，同时立即订购，每登录一次则如此操作100次。因此关于每次登录，检验程序就需要运行100次，包
43、含验证账户信息与根据购物车（一个分布式处理系统）的内容处理订单；3 .退出。需要注意的是本测试中实际分布式处理事务与总的系统请求比率为1：5,由于服务器的检验程序是一个5步骤、5页面的订单确认/订单处理程序。该分布式处理平台运行在4CPU程序服务器上，用户登录数量达到最大值，所测试的每个程序服务器产品，其持续吞吐量如下表所述：图14：分布式处理平台测试结果程序服务器最大用户登录吞吐量每秒钟分布式处理事务所下订单价格/性能IJ2EEApplicationServerA4,00059TPS$1,305J2EEApplicationServerB1,00018TPS2（不能支持，见脚注）$4,722
44、（见注释2）.NETl.O/WINDOWS20004,00079TPS$468.NET1.lAVindowSeNETServer20036000117TPS$31631参见附录2,应用程序服务器系统硬件/软件总表2J2EE应用程序服务器B不能在分布式处理平台连续2个小时支持最大用户负荷。它也不能连续4个小时支持任何吞吐量，超出这个时间将会出现错误。3估计值，根据WindOWS2000AdvancedSerVer价格。Windows.NETServer2003价格未公布。图15：用MezrvryLOadRlmner分析J2EE应用程序服务盎A心行结果.,显示24小时的吞吐量。该图描述连续24小时
45、Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第二部分处理事务的验证量。注意：前6个小时吞吐量略有下降，而后TPS则稳固在24小时的平均处理水平59个命令/每秒。图16：用诙TCQjLoadRunner分析J2EE应用程序服务器R运行结果，显示了24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第 二部分处理事务的验证量。UaeaaeFFe*MXr- j o*orH: R. 3W，E 一， I 6,，： r，1mm6I .J注意：分布式处理平台的峰值吞吐量不能持续2小时以上。对参数做各类调整进行四十多次测试说明，J2应用理房服务
46、痴处理数据库的分布式XA兼容处理有明显难度。以上测试具有代表性的，TPS略有下降，继而是急剧下降，上升，而后是程序服务器失败，以至于4小时以上不能成功处理请求。图17：用Me旗LOadRUrU吩析MiCroSoft.NET1.0/Windows2000Se”运行结果，显示了24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第二部分处理事务的验证量。图18：用fe也”LoadRunnerytf（Microsoft.NET1.1/Windows.NETSee2003运行结果，显示了24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处理量。注
47、意，实际订单操作（分布式处理）是第二部分处理事务的验证量。注意：吞吐量24小时持续稳固，24小时平均命令处理的TPS是117个/秒。Web服务基准由于Web服务作为应用程序服务器的一项新领域已经被广泛的推出，因此新的PetStore基准的扩展功能就是用来检验一个原型Web服务的每一个应用程序服务器的性能。由于Web服务自身的规定，因此它能够提供现实的测试实例来证明应用程序服务器的性能，以通过SoAP激活基本目标与将简单与复杂数据类型/对象串行化为XML文件的性能。PetSIore中的Web服务的功能就是将单个输入参数作为一个定单ID,然后执行在数据库中寻找这个定单的动作，最后将定单对象作为XML文件返回给调用程序。定单对象本身既包含简单数据类型（字符串、整数型、小数型）也包含数组（代表某个条目全面的排列项）。图19.从基于SoAPLI的Web服务调用返回定单对象的
