应用程序服务器与Web服务基准比较

1、Middleware 公司J2EE和.NET应用程序服务器与Web服务基准比较Middleware 公司，2002 年 10 月Middleware公司简介Middleware公司致力于提供先进的企业Java技术培训与咨询服务。公司成立于1998年， 其宗旨是帮助企业向Java平台转移来促进电子商务项目的成功。公司协助世界上一些最大型 的机构例如BEA、Oracle、CiscoNcxtcl、MetLifeSterling mcrcc、Standard&Poors以及许 多其它企业在Java专家的指导下熟练掌握平台，减少风险，维持成本效益。这些专家都是有 着雄厚的开发经验以及强大的服务器方而技术

2、的资深工程师，同时他们还是该领域著爼的带 头人。公司的服务包括Java2. E、J2EE和XML-Web服务的现场培训，体系结构咨询以及遍 布世界课程培训。这些课程在北美以外的地方都拿到了课件许可证。Middleware公司同时 创建了ThcScrvcrSidc并一直维护着该，这个是目前领先的在线J2EE社区。 2002 Middleware公司目录表序言比较是公正的吗？修订过的Java Pet Store利用新的企业功能扩充Pet Store. 改进的Java Pet Store应用程序改进后的.NET Pet Store2.0新的实现的比较状态/高速缓冲存储数据的一个比较扩展的基准WebW

3、eb应用程序基准24小时分布式事务基准价格性能度量WebWeb服务基准测测试实验室与测试软件产品测试MicrosoftMicrosoft .NET.NET测试前.NET.NET协调以及优化配置需要的时冈NETNET协调与优化配置.J2EEJ2EE测试前J2EE协调以及优化配置需要的时间.J2EE协调与优化配置Web应用程序基准测试测测试方法24小时分布式基准Web服务基准Web服务基准直接WebWeb服务请求WEB服务基准一一远程SOAP客户端请求 附录1一一代码行对比 附录2Web应用程序基准的基准数据关闭图片下载吞吐量数据事务响应时间（秒）打开图片下载吞吐量数据量数据（每秒的图片与页面的数

4、量）数量） 附录324小时分布式事务基准的基准数据 附录4一一Web服务基准的基准数据来自于负载源的Web服务宜接SOAP激活吞吐量（每秒的响应次数）响应时间（秒）Web服务远程SOAP客户端调用吞吐量（每秒的响应次数）响应时间（秒）附录5 2EE应用程序服务器A的协调Web基准分布式事务基准Web服务基准附录6J2EE应用程序服务器B的协调Web基准分布式事务基准Web服务基准附录7 .NET l.OAVINDOWS 2000服务器协调基本全局变量的修改：Web基准分布式事务基准Web服务基准附录8.NET L1AVINDOWS.NET服务器2003协调 基本全局配置的改变：Web基准分布式

5、事务基准Web服务基准序言2001年5月，Sun微系统（8）将JavaPet Store作为基于J2EE的Web应用程序的示X实现推 出。Sun公司宣布，JavaPctStore应用程序阐述了一些最好的J2EE开发经验，为客户在创建他 们自己企业的Web应用程序时提供了一个可参考的设汁模型。Sun公司在java.siin./bliicprints/ 上提供对一系列Java Pet Store网址的维护Java Pet Store是众多领先的J2EE应用程序服务器 中的一个基础的例子。2001年11月，Microsoft宣布它已经利用Microsoft .NET Framework和C#重新实现

6、了 Java Pct Store,以此来表明.NET平台相对于J2EE的优越性。.NET Pet Shop与Sim Java PetStore 功能上是相同的，但它是利用Microsoft改进的体系结构创建的，这个体系结构是为基于 ASP.NET和.NET通用语言运行时（CLR）的n层Web应用程序开发的。Microsoft已经发布 T.NET Pet Shop的基准信息，以此来表明在髙用户负载下，.NET Pet Shop在性能上比Java 同类产品有明显的提髙。这一基准比较的结果是基于对.NET Pet Shop性能与Oraclcd发表的 运行在0racle9iAS上的Java Pct S

7、tore基准性能的比较。最新的基于.NET Pet Shop 1.5的比较可 以从下而的网址获得：.go（domct./tcam/parc/vcritcst.aspx 然而，许多Java开发商以及Sun. IBM和Oracle坚持认为目前的比较并没有实际意义，因为Sun的Pet Shop应用程序蓝图还没 有进行性能优化，因此并不表示它就是基准。这篇报告包含了由Middleware公司得出的基于Java Pet Store最新实现的一系列广泛的新 基准结果。这一新的实现在性能和伸缩性上都作了广泛的优化，测试是在两台先进的、市而 上可以买得到的J2EE应用程序服务器上进行的。新的实现同时还扩展到支

8、持两个物理数据 库之间分布式适应XA事务。此外，实现中还增添了一项基于XML的Web服务和Web服务客 户程序。为了基准的比较，Microsoft也已经向Middleware公司提供了相应功能的修订过 的.NET Pet Shop 2.0应用程序，该应用程序遵循相同的规X,井且Middleware已经完成了对 它的审查工作。这个实现包括通过由+服务的.NET组件支持分布式事务：同时具有修订的 J2EE实现中相应的Web服务功能。本文详细阐述两种新实现的性能与伸缩性广泛基准的比较 结果。比较是公正的吗？从最初开始，许多Java开发者坚持认为原始的比较是无效的，因为Sim的版本在开发效 率和性能上

9、都没有进行优化。Java开发者指岀，Microsoft实现经过了专门的性能优化，并且 与Sim的版本使用的是不同的体系结构。例如，Java开发者指出Microsoft在他们的实现中使 用SQL服务器贮存程序（Sun的Java版本使用的是动态SQL,这样使得数据库移动更加方便）， 这是这两种不同实现的关键区别，这一区别使得.NET版本比Java同类产品运行更加快速。对 于这一点，Microsoft坚持认为Sun的应用程序是被作为一个J2EE企业设计最佳实践模板推出 的，因此，完全有理由认为应用程序在可伸缩性已经作过了相当好的调整。Microsoft指出它 也采用类似的方法将所有.NET Pet

10、Shop源代码作为.NET企业设汁模板的最好实践发布：它 使用贮存程序的原因基于这样的一个事实，那就是许多的企业DBA为了控制的方便更趋向 于将查询封装在贮存程序，同时许多人甚至不接受在应用程序中的动态SQL。然而，网上的 Java开发者例如TheServerSide.却提出了合法性的问题，例如：难道J2EE版本不能够重新编写，对其进行优化以实现更好的性能？如果.NET版本不使用贮存程序，而是使用与J2EE版本里相同的动态SQL,那么英性能会 发生什么变化呢？对比是否可信？尽管原始的比较使用的硬件是类似的，但并不是相同的，并且比较是由 Oracle和Microsoft%自的实验室完成的，使用的

11、是不同版本的Mercury LoadRunner负载 测试软件和不同的测试台。修订过的Java Pet Store精通基于Web的J2EE应用程序服务器的Middleware公司，根据Java社区的反馈信息以及 企业开发者公布在TheServerSide上的反馈信息，使用J2EE和E从新创建了Java Pet Store,对 其性能进行了充分的优化，确保新的实现仅仅包含执行应用程序所需要的代码，而没有那些 只是用来表明J2EE特征的代码。同时Middleware公司将Pet Store应用程序的功能扩展到支持 重要的新的企业功能，这些功能包括分布式、适应XA事务以及基于XML的Web服务。这一

12、 新的应用程序已经被作为Middleware的Java Pet Store 2.0公布在TheServerSide0同时 Microsoft也将他们的.NET Pet Shop升级到2.0版，增添了支持分布式事务与Web服务的功能, 在.NET应用程序中使用所有的动态SQL来代替贮存程序。Microsoft已经将这个新的.NETPet Shop 2.0版本发布在MSDN上,供.NET开发者在创建他们自己的n层Web应用程序的时候作为 一个蓝图使用，同时Microsoft也在ServerSide上公布了源代码。Middleware公司在新的实现中完成了一系列广泛的基准，使用的是与应用程序服务器和

13、 数据库后端系统相同的硬件，并且采用了相同的测试台。本文包括了这些有Middlcware公司 执行并且验证的测试的结果。这些测试包括广泛的J2EE应用程序服务器协调与优化，都是 在2002年6月到9月的四个月的时间内进行的。Middleware公司颁布的基准的基本规则包括：1.J2EE与.NET实现在功能上必须100%的相同，在行为上没有任何的区别。2.两个实现都必须是根据最佳实践代码准则创建的，这样现实中的消费者在创建他们自己 的应用的时候可以遵循每一项有效设计模式服务。3.每一个应用程序在逻辑上都必须是三层实现，使用分割好的组件来封装中间层商业和数 据访问逻借。4.应用程序必须设计得使它们

14、都能够跨多中间层应用程序服务器群集来缩小。5.基准必须与能够响应现实世界产品配苣的现实的应用程序服务器和数拯库配置设宜一 起运行。6.所有的基准应用程序源代码、数据负载以及测试脚本(包括.NET和J2EE)都必须公布在 Serverside.上，这样客戸可以复制并验证英结果。在基准中使用的源代码、数据库结构 以及测试脚本可以从下面的网得到：.middlewarepany./i2eedotnetbench/。利用新的企业功能扩充Pet Store.为了使新的基准更加易于充分理解，J2EE和.NET中的Pct Store 2.0应用程序需要扩展重 要的新的企业功能，其中包括：分布式事务。在原始的S

15、un的Java Pet Store中，所有的数据库事务都发生在单个的数据库 中，而在Pet Store 2.0基准中，对于每一条命令，都有一项分布式的事务在两个不同的物 理数据库之间执行，命令信息放在一个数据库中，而存货统计在另外一个数据库中进行。 如果事务中有任何一部分失败，那么整个事务就会再从头开始。创建这样的应用程序与 基准的目的是对使用JTA事务服务的J2EE E与通过利用+事务的.NET服务处理的.NET事 务的性能进行对比。 Web服务。Pct Store 2.0包含有一项以XML格式提供命令信息的Web服务，这些信息包 括所有命令的详细内容和每一条特殊命令的排列项。Web服务在S

16、OAP1上工作。除了 Web服务本身外，Pet Store 2.0还包含一个用来调用Web服务在浏览器中显示结果的简单 的客户程序包。改进的Java Pet Store应用程序Java Pet Store应用程序通过许多途径来改进增加其性能。修订后的应用程序仍然保持具 有E基础的设计模式，类似由J2EE升级而成的可缩放n层企业应用程序。然而，许多性能上 的改进对应用程序进行了彻底的性能优化，下而将详细的介绍这些性能的优化。事务边界的改进：尽管大部分原始的Pet Store应用程序遵循应用程序的标准访问模式, 调用一个E会话，这样完成一个事务就需要调用所有需要的E实体。改进后这种方法并没 有在所

17、有的情况下延续，因为它会导致原始的实施中某些性能的退步。例如，在某一类 别所包含的产品报表中，三种各包含有三列的产品需要九次事务才能完成，而不是一次。 在改进后的Middle Java Pet Store 2.0中,所有的事务边界都被修改以最小化事务次 数为E实体实现了一种Read-Mostly模式：在原始的PetStore中，所有的实体都是读写式。这 种模式开发简单，但是效率低下，因为每一次操作都会导致读写数据库一次，即便是对 静态数据的操作也是如此。为了减轻这个问题的影响，有些适当的实体块被以一种 Read-Mostly的模式重新实现。在这种模式中，E实体被分成两个部分：一部分为只读模 式

18、，其状态保存在事务边界中，另一部分为写模式；两部分实体都分享一个引用，这个 引用指向代表它们的数据的通用数据结构。只读实体块界而包含有访问方法，而写实体 块界而包含有改变方法：所有的数据库读的方法都包含在只读模式E中，例如eLoad(), 所有的写数据库方法都包含在写模式E中，例如eStore()o此外，在整个实体中添加了 isModifiedO方法，该方法可以写入数据库这样所有不必要的数据库更新都可以避免。改进了数拯库索引的使用：改进后在一般的搜索方而都可以使用索引，例如搜索产品的 名字以及样品ID。此外，原始Pet Store的表格生成脚本中的一个主要关键字被忽略了， 而这个关键字往往使得

19、详细目录的访问非常的慢。去掉多余的JNDI査找和调用初始化：每一个数据资源与E原参考都储存在应用程序服务 器的JNDI服务中。在原始的Pet Store中，每次在这些参考被使用的时候，系统都要找岀 JNDI初始背景，然后在JNDI中查找相应的参考。两者都仅仅只需要做一次就可以了。代码的改变使得所有不必要的JNDI调用都省去了。动态类只有一次初始化：在Pci Store中使用的一种在编译的时候载入不知需的类的设计 模式就是用来显示Java的灵活性的。它通过查找将要作为字符串使用的类的划字，使用 forName()操作来为该类生成实例来完成。然而，进程的灵活性的代价就是执行上的髙耗 费。那些类的爼

20、字在编译时已经知道的情况下，程序将这一过程移除同时类的名字被编 码。在苴余的情况下，程序确保类的查找和确左只执行一次，然后只有在此类生成新的 实例的时候再次执行。就像前而提到的一样，还有许多其他的改进：包括广泛的使用JDBC预泄义的语句，对 字符串处理的重大改变以及其它的重大改进。然而，上而详细列出的这些改变带了了性能上 的最大的改观。基于J2EE应用程序服务器A比较性的性能数据，与Sim公司最初实施的Java Pet Stored Lt,这些优化大致对性能提高了 17倍。这一数据是根据对进行性能平衡(对分布 式事务的支持，数拯的髙速缓存)后原始Sun Java Pet Store 新的Mid

21、dleware J2EE Pet Store 2.0的比较得出的。新的实施与旧的实施相比，性能上的提高见下表：图 1.原始的Sim Java Pet Store 口优化后的E Java Pet Store 2.0経值吞叶.量的比较Peak Throughput4 x 550 MHz CPU Application Server改进后的.NET Pet Store2.0和Java Pet Store类似，.NET Pet Shop 2.0的体系结构是由Microsoft推出的3层逻辑结构， 其目的是为了创建基于.NET的可缩放的企业应用程序。然而，在某些关键的地方，代码基 础已经作了最新的改进，

22、同时做了性能上的提高。最主要的改变包括：1.对于所有的数据库访问，使用动态SQL代替贮存程序。这样就消除了关于性能的提髙是 通过加入编译过的贮存程序，牺牲了数据库的轻便实现的争论。2.在命令布置中使用了分布式事务。3.使用一种基于SOAP的Web服务来返回命令的详细信息以及调用客户页面。4.使用数据转发器控制代替数据栅格控制来提高性能。5.使用简单的数据髙速缓冲存储器在中间层数据缓冲存储器中缓冲静态只读产品信息。新的.NET Pet Shop 2.0以及其完全体系结构白皮书可以从下而的网址下载： msdn.inicrosoft 力 ibrary/default.asp?url=/library

23、/enus/dnbda/html/bdasamppet.asp.新的实现的比较改进后的Java Pet Store实现仍然保持忠实于Sun微系统发布的Model-View-Controller体 系结构，充分利用包括会话块与实体块的J2EE核心特征的优势。在对软件进行上而详细列 出的为优化性能而做出的广泛修改的同时，软件方面由Sun微系统推荐的基本设计模式以及 广泛应用的面向对象的开发方式仍然保持完整无缺。这一体系结构使得用户界而与中间层商 业逻辑以及数据访问逻辑完全分离，后端进程被封装在不同的E中。类似的，.NET Pct Shop 2.0也采用了完全而向对象的n层体系结构，为中间层和数据访

24、问目标实施了C#类。这样它就 实现了通过使用ASP.NET Web表单将UI与中间层商业逻辑完全的分开，而ASP.NET Web表 单则通过使用一种code-behind模式（服务器端的代码通过封装与客户端HTML分开）将 HTML和客户端单元与服务器端进程单元完全分开。Web表单模式利用了框架中提供的 ASP.NET服务器控制的优势，为大部分的UI/外观单元服务，例如列表，网格等。反过来， 服务器控制激活用C#语言书写的封装在单独的.NET集合（封装的、可重复使用的组件）中 的中间层对象，这些中间层间接的通过封装在数据访问逻辑中的单独的一套数据库访问类在 访问数据库。状态/髙速缓冲存储数据的

25、一个比较为了使得呈现在用户而前的数据库信息尽量是最新的，必须确保两种实现有相同的行 为。基本上来说，核心静态产品数据一般每24小时从数据库更新一次（尽管搜索仍然会査询 数据库关键字来确立髙速缓冲存储器中的哪些记录需要显示，但是主要是在运行测试的时候 在中间层高速缓冲存储器查找），而消费者数据和用户目录却需要在每一位用戸登录的时候 都访问数据库，同时从数据库中更新帐单信息，这也是结帐过程的一部分。此外，所有产品 详细目录的数量必须精确响应所有显示这些信息的应用程序页而更新后的数据库信息。Java 版使用实体块来维持状态数据库信息；而.NET版使用.NET中间层髙速缓冲存储器来储存静 态（只读）产

26、品信息，髙速缓冲存储器每24小时更新一次。考虑到数拯的过时，这种配置在 产品间具有相同的欣慰。在这一基准中，尽管.NET和J2EE.应用程序服务器都被测试岀支持 页而输出高速缓存，但是动态页而输岀缓存并没有使用。这样的决策的目的是强调中间层应 用程序逻辑处理的性能。扩展的基准这一基准包含有三套单独的测试，这些测试可以为两个应用程序.NET和J2EE性能与缩 放性特征提供一个公平全而的概括。这三套基准包括：1.Web应用程序基准2.24小时基准分布式事务基准3.Web服务基准WebWeb应用程序基准这一基准联系应用程序大部分的基本功能，在使用Oracle和Microsoft的测试中，两个应 用程

27、序的工作量相似，但并不相同。测试的目的是得到应用程序在低用户负载量到髙用户负 载量的过程中吞吐量曲线以及测量响应时间，不给两种产品施压以测定他们分別在2个、4 个和8个CUP应用程序服务器的配置下能够支持的用户数量的极限。测试脚本在有10秒缓冲 时间的情况下执行（在Oracle的原始基准中，使用了20秒的缓冲时间，这就意味着与新的基 准相比，在相同用户负载疑的情况下，服务器所承受的压力只有一半）。页面输岀髙速缓冲 存储也被停止，这样保证服务器必须处理收到的每一条请求。不同用户负载量下的数拯点都 被单独的测量，冋时测戢ramp-up、settledown数据收集和ramp down时间来测左结果

28、的精 确性（每一个单独数据点的总执行时间都超过1小时）。为了得到更多的信息，这套基准以 两种不同的方式执行：a.关闭图片下载：这样只有基本应用程序服务器引擎被使用到。这一测试可以显示产品操 作包括服务器端脚本、会话状态管理、对象激活以及数据库连通性在内的应用程序逻辑 的良好程度。b.打开图片下载：模拟一个浏览器髙速缓冲存储器这样，每个访问站点的用户在一次脚本 重复期内都需要下载每一X单独的图片一次。这一测试可以显示应用程序服务器作为 Web服务器/应用程序服务器的综合工作的合适程度。注意,这一基准的结果不能与过去Owcle and Microsoft公布的Pet Shop的基准数据比较,因 为

29、使用了不同的测试脚本和缓冲时间,同时在应用程序的某些功能方而也与原始的Pel Shop 基准有差别。24小时分布式事务基准设计这一基准的目的是为了对每一个测试产品的分布式事务执行能力进行测试。测试脚 本包括用户登录、然后单独的处理一条100条项目的命令。命令中每一条项目结帐过程的完 成包括这个过程的最后一步就是用来激活一次分布式事务的命令的实际布置，脚本的最后是 退出。每一个用户在一个用户会话中都会完成100次单独的分布式事务。测试会在每一个产 品能够产生峰值吞吐量的用户负载下运行，并且持续24小时来观察这种吞吐量是否可持续。价格性能度量除了绝对性能度量外，每个产品基于4-CPU配置在24小时

30、的运行中的价格度量也被汁算 出来了。这一度量是以每次事务每秒花费的美元数来汁算的。花费包括中间层的硬件的开销、 应用程序服务器软件许可证开销（以4-CPU配置的每个产品的发布价格来计算）再加上用于 应用程序服务器的操作系统的购买价格。价格度量中没有包括数据库许可证费以及接下来的 支持维护费用。WebWeb服务基准这一基准测虽为J2EE和.NET服务的Web服务的性能特征。测试包括两个基本的配置：a.Web服务的直接激活使用100台分布式的物理计算机，每一台模拟多用户生成直接 SOAP调用来激活Web服务。这一基准测试应用程序服务器处理SOAP请求的能力以及作 为Web服务提供者的能力。b.We

31、b服务的远程激活应用程序服务器通过一个代理对象。在这种配置下，一共配置两 台物理的应用程序服务器，一台作为一个远程Web服务提供者（就像测试a中的那样）做 工，期外一台作为Web服务客户端而工作。100台物理客户端汁算机向应用程序服务器 计算机发送HTTP/HTML请求形成负载，应用程序服务器汁算机接着向Web服务提供者 计算机发送SOAP请求。设计这一测试的目的是测试应用程序服务器Web服务客户端性 能以及发送基于对象激活的远程SOAP的性能。测试实验室与测试软件由Mercury交互式代表在实验室里安装和配置Mercury LoadRunner 7.5。测试是在大规模 的实验室里进行的，这种

32、实验室包含有100台客户端汁算机，能够在保证客户端在系统中不 成为瓶颈的同时产生高同步性的用户负载。实验室采用CISCO吉比特主干线，每台服务器配 置两个吉比特网卡，每一个网卡包含50个客户端子集。这样配宜的目的是为了保证在测试的 过程中Web不会成为瓶颈。在吉比特Web中同时还配置了两台单独的数据库服务器。应用程序服务器测试在paq ProLiant8500服务器上运行，分别配有2、4、8个8550MHz的CUP和2GB 的RAM （对2CPU和4CPU设置）以及4GB的RAM （对8CPU设豊）。两个数据库也是paq ProLiant8500服务器，每台服务器使用8550MHz的CPU以及

33、3GB的RAM,同时增加了光纤光 学控制器来加速paq RAID存储队列。数据库、客户端和Web利用在测试过程中都被监控以保 证这些设备不会成为瓶颈。在所有的J2EE和.NET的实例中，测试会精确的报告用于应用程 序测试的应用程序服务器软件本身的能力。酗基础Web应用程序基准、24小时分布式事务基准以及Web服务直接SOAP激活基准测试的 实验室布置。Test Lab Configuration图3.带有在应用程序服务器之间远陛OAP调用的远程/代理Web服务基准测试的实验室布置50 Clients orn 101 1.x Subnet50 Ctents on 192 *1680* SubnM

34、CorralCUUMMmiDiUbtMLat Cni ty 6C吟yTest Lab Configuration产品测试产品测试MicrosoftMicrosoft .NET.NET对于.NET产品，Middleware公司测量的是英商业发布的运行在Windows 2000下 的.NETFramework 1.0 （SP2）以及在Windows.NET Sever 2003的RC Build 3681创建4322.508 的.NETFramework 1.1 RC。在测试中作为后端使用的是Microsoft SQL服务器2000数据 库。.NET 1.0 and .NET 1.1在配置上的精确

35、优化在附录7.8中给出。测试前.NET.NET协调以及优化配置需要的时间.在开发出.NET Pet Shop 2.0后（这个应用程序实际上是由一家设立在California的 Microsoft解决方案提供者开发成功的），一个Microsoft员工花了大约2个星期的时间试运行, Middleware公司测试前（单人2周的工作量）对程序进行包括配苣设置方面的优化。 NETNET协调与优化配置.优化就是在.NET Framework设置的基础上作些微小的变化。优化包括：1 确保数据库正确的协调，拥有足够的存储空间来为小时事务的沉重运载量分配存储空间。2.对基础ASP.NET设置作了修改，使得表单认

36、证可以与基于Windows的认证对比，因 为应用程序本身是一个能够通过任何拥有标准窗口的客户端平台访问的稀少客户应用程序（认证是以一个记录有用户名和密码的数据库为基础的）。3.将ASP.NETI作器和10线程从25个（Windows2000的缺省设置）下调到20个：微小 的上调在Web服务运行期间每一个客户端IP被允许的Web连接的数量来保证服务器允许每 个负载生成客户端可以激活足够多的向.NET应用程序服务器的同步Web连接。4.在Windows2000的测试中，设置ASP.NET进程模式以便.NET应用程序可以运行在与 IIS Web服务器一样的进程空间。5.在Windows.NET Se

37、rver 2003的测试中,使用了新的HS 6.0进程模式（缺省设置）, 因为这样可以产生比Windows2000更好的性能，同时允许应用程序在与HTTP服务器分离的 atCMEaupATAC-caoPLfcrrjeW: Uroiy 卜nwHr Lcx*-VT3Csrrcir0Mw dAtpMovloft1SoMet ”乂eAa$M4!X*W.II 4指泄的服务器进程（应用程序存储池）中运行。6.在Windows.NET服务器下，两个工作器进程可以在4CPU和8CPU系统的IIS服务管理 中运行。ASP.NET工作器进程由Windows.NET服务器的ASP.NET自动的产生与监督，类似 于利

38、用J2EE应用程序运行应用程序服务器复制的槪念。J2EE对于J2EE产品，使用两种领先的J2EE应用程序服务器来实施测试，在这篇报告中，我 们用J2EE应用程序服务器A和J2EE应用程序服务器B来分别表示。由于授权限制，因此 Middleware不能够透露被测试的J2EE应用程序服务器的划字。然而，选择的测试的产品代表 了目前广泛使用的、在市场上可以自由购买到的企业J2EE应用程序服务器。J2EE应用程序 服务器的测试采用0racle 9i后端数据库，因为这种数据库是每种产品首推使用的数据库，拥 有完整的J2EE/JDBC应用程序服务器特征的支持。两个应用程序服务器都RcdHat Linux

39、7.2 和Windows 2000 Advanced Server （SP2）进行了测试。Middleware对两个应用程序在不同的操 作系统下运行作了比较，最后使用能够为应用程序服务器提供最佳性能的操作系统的测试结 果来公布。对于J2EE应用程序服务器A来说，采用Windows 2000操作系统因为在该系统下这 个应用程序服务器的性能明显的好于在Linux 7.2操作系统下；而对于J2EE应用程序服务器B 来说，在Windows 2000和Linux 7.2系统下性能相似，但是测试中还是选择了Windows 2000 主要是因为在这一系统下更容易监督计算机在有负载的情况下的性能特征，而不必再

40、使用快 入的Windows 2000性能监督器以至影响其性能J2EE应用程序服务器A和J2EE应用程序服务 器B精确配置优化在附录5-6中给出。测试前J2EE协调以及优化配置需要的时间.在J2EE优化后的应用程序开发成功后，两个有经验的Middleware公司的员工（全天）在 进行最后的数据点测量前（单人10周的工作量），花了将近5个星期的时间为J2EE应用程序 服务器A协调以及优化配置。同时还花了将近5个星期的时间为J2EE应用程序服务器B （单人 10周的工作量）协调以及优化配置。对两台J2EE应用程序服务器的调整和优化配程过程是 非常重要的，下而将会详细的讲解。J2EE协调与优化配置J2

41、EE应用程序由Middleware家根拯最有经验的销售者的指导对测试的不同的应用程 序服务器产品分别作了广泛的协调。协调包括用不同的Java Runtime Environment （JRE）以及 数据库驱动程序检测产品以得到最优组合：以及基本应用程序服务器设置优化，例如堆阵规 模、高速缓冲存储块以及线程设置。在对两个应用程序服务器的协调过程中，首先考虑到的是将要使用的Java Runtime Environment （JRE）和JDBC驱动器的选择。这里，一共测试了四种JRE： SunSoft 1.3和1.4、 JRockit 3.1 以及IBM 1.3。对于应用程序服务器A来说，SunSo

42、ft 1.4是最快的，在基准中可以比SunSoft 1.3产生多 出50%的吞叶量。然而，因为SunSoft 1.4的兼容性问题，它能够用于Web应用程序和分布式 事务基准，却不能够用于J2EE.应用程序服务器A来做Web服务测试，所以在这里选择了 JRockit JREO这些JRE性能的一个重要的因素就是并发的碎片收集实现。如果这个特征不能 够实现，那么由于碎片收集导致的暂停就会变的多余并且会导致在高负载疑时发生“拒绝连 接”的错误，因为应用程序服务器进程在碎片收集的过程中会停止工作。因为比SunSoft JVM1.3相比提供更加优化的碎片收集的SunSoft JVM 1.4与产品一起工作（

43、在Web服务测试中例 外），J2EE应用程序服务器A会从中受益。然而J2EE应用程序服务器B不与SunSoft JVM 1.4兼容，因此，只能够使用SunSoft JVM 1.3。这个JVM能够为J2EE应用程序服务器B提供最佳的优化性能，尽管与SunSoft JVM 1.4 相比，碎片收集仍然存在缺陷。结果发现，应用程序服务器B通过使用应用程序服务器的前 后Web服务（一个单独运行的进程）来调节引入到应用程序服务器本身的请求可以获得更可 靠的性能。这是由销售者B为他们的应用程序服务器推荐的实际经验。通过适肖的调肖引入 到应用程序服务器的并发请求的数目可以使得服务器在相同的负载情况下运行更加快

44、速与 可靠，同时也可以把碎片收集的影响最小化。使用应用程序服务器的Web服务器的确是需要 配宜与调整来达到最优化的设n. Web服务器关键的配置变更是指现在在一个设置中，这个 设宜限左Web服务器与应用程序服务器启动是并发的连接与线程的数量。这个设宜被设宜得 相对比较低（50个线程），以保证对引入Web服务器的请求排队，同时保证应用程序服务器 引擎中的队列十分小。设置的调节必须与应用程序服务器本身线程的调节一致，而这一过程 是相当复杂的。但是最终这个设程能够保证应用程序服务器引擎本身在大量的请求压力下永 远也不会瘫痪，这样就会运行得更加可靠。如果Web服务器的配置允许太多的用户同时连接， 那么

45、吞叶量将随着应用程序服务器的不稳左而显著下降。即使是经过了这样的大量的调节 后，在Web应用和分布式事务基准中，J2EE应用程序服务器B性能仍然不能像J2EE应用程序 服务器那么好。与JTA分布式事务协作（这一特性在两个基准的测试中都被激活）性能差是 一个主要的因素，这就需要使用1.3JRE代替1.4JRE。JDBC驱动器的选择需要基于以下标准：特性的实用性：对事务的支持以及可滚动的结果设置整体性能一共测试了四种驱动器：数据库提供者的驱动器（Oracle）.应用程序服务器提供者的 驱动器以及两个领先的第三方驱动器提供者。在排除掉那些没有必备特征的驱动器后，剩下 的驱动器在负载下作了性能与稳左性

46、测试。在决左采用JRE和JDBC驱动器后，应用程序服 务器同时作了应用程序服务器参数和Java运行时间参数协调。除了协调额外的服务器实例 外，通过在应用程序服务器引擎上运行多个服务器进程使得性能得到了很大的提髙，应用程 序服务器引擎使用DNS在服务器实例间平衡负载。这种配置对两个应用程序服务器的大部分 都是最理想的，因为它允许使用服务器上所有的内存，然而，每一个兼容产品必须单独使用 更少的内存用于碎片收集，这就意味着周期性的碎片收集将会更加快速，减少进程相应的暂 停时间。Web应用程序基准测试该平台包含两个脚本，比重各占一半，一个脚本用以模拟用户简单的浏览网址，另一 个则模拟从寻找以及购物。在

47、只有浏览功能的脚本中，用户需要如下操作：1.登录主页：2.对1000种产品进行三次任意的文字查询，在每次査询结果的网页上，单击“下一步” 按钮；3.在某种X围内检验产品，重复三次：4.对某种产品具体内容检验三次（包括产品存货纪录的实时读取）：对于具有浏览和查询功能的脚本，模拟用户需要：5.对1000种产品进行两次任意的文字查询，任每次査询结果的网页上，单击“下一步” 按钮：6.利用100, 000个用户中的任意ID,在注册；7.在购物车中添加50000个中的两个项目；8.检验，确认账户信息，然后根据购物车中的项目下订单；9.有一半时间用户用于退出操作，而一半时间不是这样，于是，50%的活动彼关

48、闭， 同时放弃这50%时间使得应用程序服务器可以处理关闭操作，关闭时间设左为10 分钟，即如果10分钟内没有任何操作，则关闭之。这种做法是頁正的电子商务对现 实活动的合理模拟。10.购物完成后，执行最后一次文字检索。测试方法测试方法对每种产品进行测试都包含两个完全独立的方法，一种是关闭图像下载功能，另一种 是开通图像下载功能（客户端具有浏览器缓存）。这么做是为了更全面的了解应用程序服务 器性能，该性能包括两个方面，一个是终端处理情景，应用程序服务器本身不为Pet Store 站点图像提供服务：另一个是一般情况处理情景，应用程序服务器处理程序逻辑，同时提供 下载图片到浏览器的功能。注意，.NET

49、 Pet Shop和Middleware J2EE Pet Store在英运行过程 中采用不同的图像。于是，就图像而言，.NETPet Shop必须加以修正，才能打开J2EE Pet Store 图片，这样每种测试产品的图像数量以及图像尺寸就相同了。期外，利用模拟浏览器缓存下载图片时，程序设置已经被固泄，因此在用户不断使用 过程中，对每个用户而言，同一图片只能被下载一次，这类似于浏览器缓存确保图片因速度 原因而在客户端存储的实际设置。于是，网页中的普通图片，例如导航条，每个用户只能下 载一次，即便他作为一个模拟用户在脚本执行过程中访问多X网页。但是每个模拟用户的 浏览器缓存都是事先固泄的，因而

50、他们必须各自重泄义自己的图像缓存。这些测试是在2个，4个以及8个CPU配置上运行的，目的在于了解当系统增加CPU 时应用程序服务器功能的垂直变化。对于每个数据点，其数据运行由数据激增，平稳，数据 收集以及数据量减小这几个部分组成。从每个数据运行一小时的综合结果来看，只有当系统 达到稳左状态时才开始数据收集。对单个产品而言，直到用户登录的响应时间达到3秒或者 更大的时候，数拯点才被获取，因为每个产品如果在这些用户登录数以上进行测试通常出错。 所以那些功能扩展到承受更大用户量的产品才可以收集更多数据点。Web应用程序结果（关闭图片下载功能）图4：吞吐量峰值图7： 4CPU应用程序服务器的吞吐量曲线

51、fmskmoQWeb Application Bdriehhidt-k h6 Peak Throughput图5：网页平均响应时间为3秒时的最大支持用戸数W6b Appliddtidh Bdnchhhdrk (nd images)Maximum User Load图6：双CPU应用程序服务器的吞吐虽曲线OMPUI4CPU|a&cpu|/Cj:二IKCtUil*12 吐* Sfw B.NY I.WCKNfl 1. WHDX ht T STMl4M5：U 2 CPU A6frh16dn 4VWfr4i&v*xECr4i&v*xEC 2CPU 4CPUD8CPU图8： 8CPU应用程序服务器的吞吐量

52、曲线Web应用程序结果（启动图片下载功能）图9：吞吐量峰值Web Applicaiioni Benchmark (imac download on)Peak Throughput图10：网页平均响应时间为3秒时的最大支持用户数Ttifauahtaix BfsrabtWf Mil (inauo deivioM o( (D 4 CPU AbdUb 94FW图13： 8CPU应用程序服务器的吞吐量曲线Web Application Benchmark (image down load on)Maxi mum Supported Users图11： 2CPU应用程序服务器的吞吐量曲线图12： 4CPU

53、应用程序服务器的吞吐量曲线4/nThieQihal BoatiOwdef MM (imiyu dounloM Ml 4 CPU ApgatMtoa4：CQ /12T/A Q/I-J5C Ettirsw AI庄 EgStfWB1亠低八CLW3C1 -*-r：T i 沁“皿底丫 11 一： 1a 1，|ThouQh|MiCMoedownload on|O CPU App5c*4-t-J2fcfc sp SttmA-型Smwb-*- fcTSV2K- NtT 1 1 从、4“ NEt 田24小时分布式基准设讣分布式处理平台的脚本是为了全面测试服务器处理大量分布式处理登录的能力， 本文的测试对象则是编

54、写命令。该脚本利用模拟用户进行如下操作：1.从10万个有效用户名中任选一个，填写资料登录：2.从5万个项目任选一个加入购物车，并且立即订购，每登录一次则如此操作100次。于 是对于每次登录，检验程序就需要运行100次，包括验证账户信息以及根据购物车（一 个分布式处理系统）的内容处理订单：3.退出。需要注意的是本测试中实际分布式处理事务与总的系统请求比率为1： 5,因为服务器 的检验程序是一个5步骤、5页面的订单确认/订单处理程序。该分布式处理平台运行在4CPU程序服务器上，用户登录数量达到最大值，所测试的 每个程序服务器产品，英持续吞吐量如下表所述：图14：分布式处理平台测试结果程序服务器最大

55、用戸登录 吞吐量每秒钟分布式处理 事务所下订单价格/性能1J2EE ApplicationServer A4,00059 TPS$1,305J2EE ApplicationServer BLOOO18 TPS2（不能支持， 见脚注）$4,722 （见注释2） ）.NET1.0AVINDOWS20004.00079 TPS$468.NETLlAVindows.NETServer 20036000117TPS$3163W-H a* 0 $用诡 為:川：S|MH-ur*|MHwtAl| ltaWkUl : m” * bMKjtf 4“叫；jH T IV応Ifft n*TbYa9. .luMOml L

56、M IM*j GiHOaal Ala|I . MMurnifliilTu 悔! Io w*幻m沁51CK* M刀awQwoQ1参见附录2,应用程序服务骼系统硬件/软件总表2J2EE应用程序服务器B不能在分布式处理平台连续2个小时支持最大用户负荷。它也不能 连续4个小时支持任何吞吐量，超岀这个时间将会出现错误。3 估讣值，根据Windows 2000 Advanced Server价格。Windows.NET Server 2003价格未公布。图15：用Mercury LoadRimner分柢J2EE应用程序服务器A运冷绕栗、显示24小时的吞吐量。 该图描述连续24小时Web请求每秒钟事务处理量

57、。注意，实际订单操作（分布式处理）是第 二部分处理事务的验证量。注意：前6个小时吞吐量略有下降，而后TPS则稳左在24小时的平均处理水平59个命令/每秒。图16：用Merciny LoudRimneM柢J2EE应用程序服务腳运行结果，显示了24小时的吞吐量。 该图描述连续24小时脸b请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第 二部分处理事务的验证量。(LitnrtWravl *I hi. Xi* 吟诂厂”卅jMfftmfi SfloilOwlkM入U卜袒/ r* &) )UI WFyfUi免ge:* ojtr：繃 1 1 o o o o o o O O； La wiuvasQi

58、vof :i*tiaK.avHMJ*xw3 H %“，rj M4治BlikCTg.l lWUR_fg?BhtyCwrc*lDBICiB并SlMlI注意，实际订单操作（分布式处理）是第二部分处理事务的验证捲。IKS 1“.*他IUflrfxxt S I9rJv注意：吞吐量24小时持续稳总24小时平均命令处理的TPS是79个/秒。注意：分布式处理平台的峰值吞吐量不能持续2小时以上。对参数做各种调整进行四十多次 测试表明，J2EE应用圍磁务翻处理数据库的分布式XA1-容处理有明显难度。以上测试 具有代表性的，TPS略有下降，继而是急剧下降，上升，而后是程序服务器失败，以至于4 小时以上不能成功处理请

59、求。图 17 ：用Merciny LoadRunner分析Microsoft NET l.OfWindows 2000Server行结果，显示了24小时的吞吐崑 该图描述连续24小时Web请求每秒钟事务处理崑_tHi-XJItf.ntitaiuH vwHIM!*!IK-M1IPMIitr1bfaFwtFM01MauQP5*巧 5QF1 OJf? 6:nor-图 18：用Merciuy L（nulRunner分析Microsoft NET 1.1/Windows.NETServer 2003运行结果，显示了24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处 理量。注意，实际订单操作（分

60、布式处理）是第二部分处理事务的验证量。注意：吞吐量24小时持续稳立，24小时平均命令处理的TPS是117个/秒。Web服务基准因为Web服务作为应用程序服务器的一项新领域已经被广泛的推出，所以新的Pct Store 基准的扩展功能就是用来检验一个原型Web服务的每一个应用程序服务器的性能。因为Web 服务自身的规定，所以它能够提供现实的测试实例来证明应用程序服务器的性能，以通过 SOAP激活基本目标和将简单和复杂数据类型/对象串行化为XML文件的性能。Pet Store中的 Web服务的功能就是将单个输入参数作为一个左单ID,然后执行在数据库中寻找这个立单的 动作，最后将定单对象作为XML文件