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

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

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

Middleware公司，2002年1()月

Middleware公司简介

©2002Middleware公司

目录表

序言...............................................................................

比较是公正的吗？..................................................................

修订过的JavaPetStore........................................................................................................................

利用新的企业功能扩充PetStore................................................................................................

改进的JavaPetStore应用程序................................................

改进后的.NETPetStore2.0...................................................................................................................

新的实现的比较....................................................................

状态/高速缓冲存储数据的一个比较..............................................

扩展的基准........................................................................

Web应用程序基准.............................................................

24小时分布式事务基准.........................................................

价格性能度量..............................................................

Web服务基准.................................................................

测试实验室与测试软件..............................................................

产品测试..........................................................................

Microsoft.NET....................................................................................................................

测试前.NET协调与优化配置需要的时间......................................

•NET协调与优化配置.......................................................

J2EE......................................................................................................................................

测试前J2EE协调与优化配置需要的时间.....................................

J2EE协调与优化配置......................................................

Web应用程序基准测试.............................................................

测试方法......................................................................

24小时分布式基准..................................................................

Web服务基准......................................................................

Web服务基准―直接Web服务请求...........................................

WEB服务基准一远程SOAP客户端请求.......................................

附录1―代码行对比..............................................................

附录2—Web应用程序基准的基准数据.............................................

关闭图片下载...................................................................

吞吐量数据................................................................

事务响应时间（秒）........................................................

打开图片下载...................................................................

吞吐量数据（每秒的图片与页面的数量）....................................

附录3—24小时分布式事务基准的基准数据........................................

附录4一一Web服务基准的基准数据..................................................

来自于负载源的Web服务直接SOAP激活..........................................

吞吐量（每秒的响应次数）.................................................

响应时间（秒）............................................................

Web服务远程SOAP客户端调用...............................................

吞吐量（每秒的响应次数）.................................................

响应时间（秒）............................................................

附录5——J2EE应用程序服务器A的协调...........................................

Web基准......................................................................

分布式事务基准................................................................

Web服务基准..................................................................

附录6一一J2EE应用程序服务器B的协调...........................................

Web基准......................................................................

分布式事务基准................................................................

Web服务基准..................................................................

附录7.NET1.0/W1NDOWS2000服务器协调.......................................

基本全局变量的修改：..........................................................

Web基准......................................................................

分布式事务基准................................................................

Web服务基准..................................................................

附录8——.NET1.1AVINDOVVS.NET服务器2003协调................................

基本全局配置的改变：..........................................................

Web基准......................................................................

分布式事务基准................................................................

Web服务基准..................................................................

序言

这篇报告包含了由Middleware公司得出的基于JavaPetStore最新实现的•系列广泛的新

基准结果。这一新的实现在性能与伸缩性上都作了广泛的优化，测试是在两台先进的、市面

上能够买得到的J2EE应用程序服务器上进行的。新的实现同时还扩展到支持两个物理数据

库之间分布式习惯XA事务。此外，实现中还增添了一项基于XML的Web服务与Web服务客

户程序。为了基准的比较，Microsoft也已经向Middlev/are公司提供了相应功能的修订过

的.NETPetShop2.0应用程序，该应用程序遵循相同的规范，同时Middleware已经完成了对

它的审查工作。这个实现包含通过由C0M+服务的.NET组件支持分布式事务；同时具有修订

的J2EE实现中相应的Web服务功能。木文全面阐述两种新实现的性能与伸缩性广泛基准的比

较结果。

比较是公正的吗？

・难道J2EE版本不能够重新编写，对其进行优化以实现更好的性能？

•假如.NET版本不使用贮存程序，而是使用与J2EE版本里相同的动态SQL,那么其性能会

发生什么变化呢？

•对比是否可信？尽管原始的比较使用的硬件是类似的，但并不是相同的，同时比较是由

Oracle与Microsoft各自的实验室完成的，使用的是不一致版本的MercuryLoadRunner

负栽测试软件与不一致的测试台。

修订过的JavaPetStore

熟知基于Web的J2EE应用程序服务器的Middleware公司，根据Java社区的反馈信息与企

业开发者公布在TheServerSide上的反馈信息，使用J2EE与EJB从新创建了JavaPetStore,对

其性能进行了充分的优化，确保新的实现仅仅包含执行应用程序所需要的代码，而没有那些

只是用来说明J2EE特征的代码。同时Middleware公司将PelStore应用程序的功能扩展到支持

重要的新的企业功能，这些功能包含分布式、习惯XA事务与基于XML的Web服务。这一新

的应用程序已经被作为Middleware的JavaPetStore2.0公布在TheServerSide上。同时Microsoft

也将他们的.NETPetShop升级到2.0版，增添了支持分作式事务与Web服务的功能，在.NET

应用程序中使用所有的动态SQL来代替贮存程序。Microsoft已经将这个新的.NETPctShop

2.0版本公布在MSDN上，供.NET开发者在创建他们自己的n层Web应用程序的时候作为一个

蓝图使用，同时Microsoft也在ServerSide上公布了源代码。

Middleware公司在新的实现中完成了一系列广泛的基准，使用的是与应用程序服务器与

数据库后端系统相同的硬件，同时使用了相同的测试台。本文包含了这些有Middleware公司

执行同时验证的测试的结果。这些测试包含广泛的J2EE应用程序服务器协调与优化，都是

在2002年6月至U9月的四个月的时间内进行的。

Middleware公司颁布的基准的基本规则包含：

1.J2EE与.NET实现在功能上务必100%的相同，在行为上没有任何的区别。

2.两个实现都务必是根据最佳实践代码准则创建的，这样现实中的消费者在创建他仅自己

的应用的时候能够遵循每一项有效设计模式服务。

3.每一个应用程序在逻辑上都务必是三层实现，使用分割好的组件来封装中间层商业与数

据访问逻辑。

4.应用程序务必设计得使它们都能够跨多中间层应用程序服务器群集来缩小。

5.基准务必与能够响应现实世界产品配置的现实的应用程序服务器与数据库配置设置一

起运行。

利用新的企业功能扩充PctStore.

为了使新的基准更加易于充分懂得，J2EE与.NET中的PetStore2.0应用程序需要扩展重

要的新的企业功能，其中包含：

•分布式事务。在原始的Sun的JavaPetStore中，所有的数据库事务都发生在单个的数据库

中，而在PetSloreZO基准中，关于每一条命令，都有一项分布式的事务在两个不一致的

物理数据库之间执行，命令信息放在一个数据库中，而存货统计在另外一个数据库中进

行。假如事务中有任何一部分失败，那么整个事务就会再从头开始。创建这样的应用程

序与基准的目的是对使用JTA事务服务的J2EEEJB与通过利用C0M+事务的.NET服务处

理的.NET事务的性能进行对比。

•Web服务。PetStore2.0包含有一项以XML格式提供命令信息的Web服务，这些信息包

含所有命令的全面内容与每一条特殊命令的排列项。Web服务在SOAP1.1上工作。除了

Web服务本身外，PetStore2.0还包含一个用来调用Web服务在浏览器中显示结果的简单

的客户程序包。

改进的JavaPetStore应用程序

JavaPctStore应用程序通过许多途径来改进增加其性能。修订后的应用程序仍然保持具

有EJB基础的设计模式，类似由J2EE升级而成的可缩放n层企业应用程序。然而，许多性能

上的改进对应用程序进行了完全的性能优化，下面将全面的介绍这些性能的优化。

•事务边界的改进：尽管大部分原始的PetStore应用程序遵循应用程序的标准访问模式,

调用一个EJB会话，这样完成一个事务就需要调用所有需要的EJB实体。改进后这种方法

并没有在所有的情况下连续，由于它会导致原始的实施中某些性能的退步。比如，在某

•类别所包含的产品报表中，三种各包含有三列的产品需要九次事务才能完成，而不是

-次。在改进后的MiddleJavaPetStore2.0中，所有的事务边界都被修改以最小化

事务次数

•为EJB实体实现了一种Read-Mostly模式：在原始的PetSlore中，所有的实体都是读写式。

这种模式开发简单，但是效率低下，由于每一次操作都会导致读写数据库一次，即便是

对静态数据的操作也是如此。为了减轻这个问题的影响，有些适当的实体块被以一种

Read-Mosily的模式重新实现。在这种模式中，日B实体被分成两个部分：一部分为只读

模式，其状态储存在事务边界中，另一部分为写模式；两部分实体都分享一个引用，这

个引用指向代表它们的数据的通用数据结构。只读实体块界面包含有访问方法，而写实

体块界面包含有改变方法；所有的数据库读的方法都包含在只读模式EJB中，比如

ejbLoad(),所有的写数据库方法都包含在写模式EJB中，比如ejbStore。。此外，在整个

实体中添加了isModifiedO方法，该方法能够写入数据库这样所有不必要的数据库史新都

能够避免。

•改进了数据库索引的使用：改进后在通常的搜索方面都能够使用索引，比如搜索产品的

名字与样品ID。此外，原始PetStore的表格生成脚本中的一个要紧关键字被忽略了，而

这个关键字往往使得全面目录的访问非常的慢。

•去掉多余的JNDI查找与调用初始化：每一个数据资源与EJB原参考都储存在应用程序服

务器的JNDI服务中。在原始的PetStore中，每次在这些参考被使用的时候，系统都要找

出JNDI初始背景，然后在JNDI中查找相应的参考。两者都仅仅只需要做一次就能够了。

代码的改变使得所有不必要的JNDI调用都省去了。

・动态类只有一次初始化：在PelStore中使用的一种在编译的时候载入不知名的类的设计

模式就是用来显示Java的灵活性的。它通过查找将要作为字符串使用的类的名字，使用

forName。操作来为该类生成实例来完成。然而，进程的灵活性的代价就是执行上的高耗

费。那些类的名字在编译时已经明白的情况下，程序将这•过程移除同时类的名字被编

码。在其余的情况下，程序确保类的查找与确定只执行一次，然后只有在此类生成新的

实例的时候再次执行。

就像前面提到的一样，还有许多其他的改进：包含广泛的使用JDBC预定义的语句，对

字符串处理的重大改变与其它的重大改进。然而，上面全面列出的这些改变带了了性能上的

最大的改观。基于J2EE应用程序服务器A比较性的性能数据，与Sun公司最初实施的JavaPel

Store相比，这些优化大致对性能提高了17倍。这一数据是根据对进行性能平衡（对分布式

事务的支持，数据的高速缓存）后原始SunJavaPetSlore与新的MiddlewareJ2EEPelStore2.0

的比较得出的。新的实施与旧的实施相比，性能上的提高见下表：

图L原始日货imJPetStore与优化后的EJBJavaPetStore2.0峰值吞吐量的比较

PeakThroughput

4x550MHzCPUApplicationServer

改进后的.NETPetStore2.0

与JavaPetStore类似，.NETPetShop2.0的体系结构是由Microsoft推出的3层逻辑结构，

其目的是为了创建基于.NET的可缩放的企业应用程序。然而，在某些关键的地方，代码基

础已经作了最新的改进，同时做了性能上的提高。

最要紧的改变包含：

1.关于所有的数据库访问，使用动态SQL代替贮存程序。这样就消除了关于性能的提高是

通过加入编译过的贮存程序，牺牲了数据库的轻便实现的争论。

2.在命令布置中使用了分布式事务。

3.使用一种基于SOAP的Web服务来返I可命令的全面信息与调用客户页面。

4.使用数据转发器操纵代替数据栅格操纵来提高性能。

5.使用简单的数据高速缓冲存储器在中间层数据缓冲存储器中缓冲静态只读产品信息。

新的实现的比较

改进后的JavaPctStore实现仍然保持忠实于Sun微系统公布的Modcl-Vicw-Controllcr体

系结构，充分利用包含会话块与实体块的J2EE核心特征的优势。在对软件进行上面全面列

出的为优化性能而做出的广泛修改的同时，软件方面由Sun微系统推荐的基本设计模式与广

泛应用的面向对象的开发方式仍然保持完整无缺。这一体系结构使得用户界面与中间层商业

逻辑与数据访问逻辑完全分离，后端进程被封装在不一致的EJB中。类似的，.NETPetShop

2.0也使用了完全面向对象的n层体系结构，为中间层与数据访问目标实施了C#类。这样它就

实现了通过使用ASP.NETWeb表单将UI与中间层商业逻辑完全的分开，而ASP.NETWeb表

单则通过使用一种code-behind模式（服务器端的代码通过封装与客户端HTML分开）将

HTML与客户端单元与服务器端进程单元完全分开。Web表单模式利用了框架中提供的

ASP.NET服务器操纵的优势，为大部分的UD外观单元服务，比如列表，网格等。反过来，

服务器操纵激活用C#语言书写的封装在单独的.NET集合（封装的、可重复使用的组件）中

的中间层对象，这些中间层间接的通过封装在数据访问逻辑中的单独的一套数据库访问类在

访问数据库。

状态/高速缓冲存储数据的一个比较

为了使得呈现在用户面前的数据库信息尽量是最新的，务必确保两种实现有相同的行

为。基本上来说，核心静态产品数据通常每24小时从数据库更新一次（尽管搜索仍然会查询

数据库关键字来确定高速缓冲存储器中的什么记录需要显示，但是要紧足在运行测试攸时候

在中间层高速缓冲存储器查找），而消费者数据与用户目录却需要在每一位用户登录的时候

都访问数据库，同时从数据库中更新帐单信息，这也是结帐过程的一部分。此外，所有产品

全面目录的数量务必精确响应所有显示这些信息的应用程序页面更新后的数据库信息。Java

版使用实体块来维持状态数据库信息；而.NET版使用.NET中间层高速缓冲存储器来储存静

态（只读）产品信息，高速缓冲存储器每24小时更新一次。考虑到数据的过时，这种配置在

产品间具有相同的欣慰。在这一基准中，尽管.NET与J2EE应用程序服务器都被测试出支持

页面输出高速缓存，但是动态页面输出缓存并没有使用。这样的决策的目的是强调中间层应

用程序逻辑处理的性能。

扩展的基准

这一基准包含有三套单独的测试，这些测试能够为两个应用程序.NET与J2EE性能与缩

放性特征提供一个公平全面的概括。这三套基准包含：

1.Web应用程序基准

2.24小时基准分布式事务基准

3.Web服务基准

Web应用程序基准

这一基准联系应用程序大部分的基本功能，在使用Oracle与Microsoft的测试中，两个应

用程序的工作量相似，但并不相同。测试的目的是得到应用程序在低用户负载量到高用户负

载量的过程中吞吐量曲线与测量响应时间，不给两种产品施压以测定他们分别在2个、4个与

8个CUP应用程序服务器的配置下能够支持的用户数量的极限。测试脚本在有10秒缓冲时间

的情况下执行（在Oracle的原始基准中，使用了20秒的缓冲时间，这就意味着与新的基准相

比，在相同用户负载量的情况下，服务器所承受的压力只有一半）。页面输出高速缓冲存储

也被停止，这样保证服务器务必处理收到的每一条请求。不一致用户负载量下的数据点都被

单独的测量，同时测量rainp-up、scttlcdown数据收集与rampdown时间来测定结果的精确

性（每一个单独数据点的总执行时间都超过1小时）。为了得到更多的信息，这套基准以两

种不一.致的方式执行：

a.关闭图片下载：这样只有基本应用程序服务器引擎被使用到。这一测试能够显示产品操

作包含服务器端脚本、会话状态管理、对象激活与数据库连通性在内的应用程序逻辑的

良好程度。

b.打开图片下载：模拟一个浏览器高速缓冲存储器这样，每个访问站点的用户在一次脚本

重复期内都需要下载每一张单独的图片一次。这一测试能够显示应用程序服务器作为

Web服务器/应用程序服务器的综合工作的合适程度。

注意,这•基准的结果不能与过去OacleandMicrosoft公布的PelShop的基准数据比较,由

于使用了不一致的测试脚本与缓冲时间,同时在应用程序的某些功能方面也与原始的Pet

Shop基准有差别。

24小时分布式事务基准

设计这一基准的FI的是为了对每一个测试产品的分布式事务执行能力进行测试。测试脚

本包含用户登录、然后单独的处理一条100条项目的命令。命令中每一条项目结帐过程的完

成包含这个过程的最后一步就是用来激活一次分布式事务的命令的实际布置，脚本的最后是

退出。每一个用户在一个用户会话中都会完成100次单独的分布式事务。测试会在每一个产

品能够产生峰值吞吐量的用户负载下运行，同时持续24小时来观察这种吞吐量是否可持续。

价格性能度量

除了绝对性能度量外，每个产品基于4-CPU配置在24小时的运行中的价格度量也被计算

出来了。这一度量是以每次事务每秒花费的美元数来计算的。花费包含中间层的硬件的开销、

应用程序服务器软件许可证开销（以4-CPU配置的每个产品的公布价格来计算）再加上用于

应用程序服务器的操作系统的购买价格。价格度量中没有包含数据库许可证费与接下来的支

持保护费用。

Web服务基准

这一基准测量为J2Eg.NET服务的Web服务的性能特征。测试包含两个基本的配置：

a.Web服务的直接激活使用100台分布式的物理计算机，每一台模拟多用户生成直接

SOAP调用来激活Web服务。这一基准测试应用程序服务器处理SOAP请求的能力与作为

Web服务提供者的能力。

测试实验室与测试软件

由Mercury交互式代表在实验室里安装与配置MercuryLoadRunner7.5。测试是在大规模

的实验室里进行的，这种实验室包含有100台客户端计算机，能够在保证客户端在系统中不

成为瓶颈的同时产生高同步性的用户负载。实验室使用CISCO吉比特主干线，每台服务器配

置两个吉比特网卡，每一个网卡包含50个客户端子集。这样配置的目的是为了保证在测试的

过程中Web不可能成为瓶颈。在吉比特Web中同时还配置了两台单独的数据库服务器。应用

程序服务器测试在CompaqProLiant8500服务器上运行，分别配有2、4、8个8550MHz的CUP

与2GB的RAM（对2CPU可4CPU设置）与4GB的RAM（对8CPU设置）。两个数据库也是

CompaqProLiant8500服务器，每台服务器使用8550MHz的CPU与3GB的RAM,同时增加了

光纤光学操纵器来加速CompaqRAID存储队列。数据库、客户端与Web利用在测试过程中都

被监控以保证这些设备不可能成为瓶颈。在所有的J2Eg.NET的实例中，测试会精确的报

告用于应用程序测试的应用程序服务器软件本身的能力。

解.基础Web应用程序基准、24小时分布式事务基准与Web服务直接SOAP激活基准测试的实

验室布置。

图3.带有在应用程序服务器之间远程SOAP调用的远程/代理讥eb服务基准测试的实验室布置

TestLabConfiguration

产品测试

Microsoft.NET

关于.NET产品，Middleware公司测显的是其商业公布的运行在Windows200()下的.NET

Framework1.0(SP2)与在Windows.NETSever2003的RCBuild3681上创建4322.508的.NET

Framework1.1RC。在测试中作为后端使用的是MicrosoftSQL服务器2000数据库。.NET1.0

and.NET1.1在配置上的精确优化在附录7.8中给出。

测试前.NET协调与优化配置需要的时间.

在开发出.NETPetShop2.（）后（这个应用程序实际上是由一家设立在California的

Microsoft解决方案提供者开发成功的），一个Microsoft员工花J’大约2个星期的时间试运行，

在Middleware公司测试前（单人2周的工作量）对程序进行包含配置设置方面的优化。

.NET协调与优化配置.

优化就是在.NETFramework设置的基础上作些微小的变化。优化包含：

1.确保数据库正确的协调，拥有足够的存储空间来为小时事务的繁重运载量分配

存储空间。

2.对基础ASP.NET设置作了修改，使得表单认证能够与基于Windows的认证对比，由

于应用程序本身是一个能够通过任何拥有标准窗口的客户端平台访问的稀少客户应用程序

（认证是以一个记录有用户名与密码的数据库为基础的）。

3.将ASP.NET工作器与10线程从25个（Windows2000的缺省设置）下调到20个；微小

的上调在Web服务运行期间每•个客户端IP被同意的Web连接的数量来保证服务器同意每

个负载生成客户端能够激活足够多的向.NET应用程序服务器的同步Web连接。

4.在Windows2000的测试中，设置ASP.NET进程模式以便.NET应用程序能够运行在与

IISWeb服务器一样的进程空间。

6.在Windows.NET服务器下，两个工作器进程能够在4CPU与8CPU系统的IIS服务管理

中运行。ASP.NET工作器进程由Windows.NET服务器的ASP.NET自动的产生与监督，类似

于利用J2EE应用程序运行应用程序服务器复制的概念。

J2EE

关于J2EE产品，使用两种领先的J2EE应用程序服务器来实施测试，在这篇报告中，我

们川J2EE应用程序服务器A与J2EE应用程序服务器B夹分别表示。由于授权限制，因此

Middleware不能够透露被测试的J2EE应用程序服务器的名字。然而，选择的测试的产品代表

了日前广泛使用的、在市场上能够自由购买到的企业J2EE应用程序服务器。J2EE应用程序

服务器的测试使用Oracle%后端数据库，由于这种数据库是每种产品首推使用的数据库，拥

有完整的J2EE/JDBC应用程序服务器特征的支持。两个应用程序服务器都在RedHatLinux7.2

与Windows2000AdvancedServer（SP2）进行了测试。Middleware对两个应用程序在不一致的

操作系统下运行作了比较，最后使用能够为应用程序服务器提供最佳性能的操作系统的测试

结果来公布。关于J2EE应用程序服务器A来说，使用Windows2000操作系统由于在该系统下

这个应用程序服务器的性能明显的好于在Linux7.2操作系统下；而关于J2EE应用程序服务器

B来说，在Windows2000与Linux7.2系统下性能相似，但是测试中还是选择了Windows2000

要紧是由于在这一系统卜.更容易监督计算机在有负载的情况下的性能特征，而不必再使用嵌

入的Windows2000性能监督器以至影响其性能。J2EE应用程序服务器A与J2EE应用程序服务

器B精确配置优化在附录5-6中给出。

测试前J2EE协调与优化配置需要的时间.

在J2EE优化后的应用程序开发成功后，两个有经验的Middleware公司的员工（全天）在

进行最后的数据点测量前（单人10周的工作量），花了将近5个星期的时间为J2EE应用程序

服务器A协调与优化配置。同时还花了将近5个星期的时间为J2EE应用程序服务器B（单人1（）

周的工作量）协调与优化配置。对两台J2EE应用程序服务器的调整与优化配置过程是非常

重要的，下面将会全面的讲解。

J2EE协调与优化配置

J2EE应用程序由Middleware专家根据最有经验的销售者的指导对测试的不•致的应用

程序服务器产品分别作了广泛的协调。协调包含用不一致的JavaRuntimeEnvironment（JRE）

与数据库驱动程序检测产品以得到最优组合：与基本应月程序服务器设置优化，比如堆阵规

模、高速缓冲存储块与线程设置…

在对两个应用程序服务器的协调过程中，首先考虑到的是将要使用的JavaRuntime

Environment（JRE）与JDBC驱动器的选择。这里，一共测试了四种JRE：SunSoft1.3与1.4、

JRockit1.3。

关于应用程序服务器A来说，SunSoft1.4是最快的，在基准中能够比SunSoft1.3产生多

出50%的吞吐量。然而，由于SunSoft1.4的兼容性问题，它能够用于Web应用程序与分布式

事务基准，却不能够用于J2EE应用程序服务器A来做Web服务测试，因此在这里选择了

JRockitJREo这些JRE性能的一个重要的因素就是并发的碎片收集实现。假如这个特征不能

够实现，那么由于碎片收集导致的暂停就会变的多余同时会导致在高负载量时发生“拒绝连

接”的错误，由于应用程序服务器进程在碎片收集的过程中会停止工作。由于比SunSoftJVM

1.3相比提供更加优化的碎片收集的SunSoftJVM1.4与产品一起工作（在Web服务测试中例

外），J2EE应用程序服务器A会从中受益。

然而J2EE应用程序服务器B不与SunSoftJVM1.4兼容，因此，只能够使用SunSoftJVM

1.3。这个JVM能够为J2EE应用程序服务器B提供最佳的优化性能，尽管与SunSoftJVM1.4

相比，碎片收集仍然存在缺陷。结果发现，应用程序服务器B通过使用应用程序服务器的前

后Web服务（一个单独运行的进程）来调节引入到应用程序服务器本身的请求能够获得更可

靠的性能。这是由销售者B为他们的应用程序服务器推荐的实际经验。通过适当的调节引入

到应用程序服务器的并发请求的数目能够使得服务器在相同的负载情况下运行更加快速与

可靠，同时也能够把碎片收集的影响最小化。使用应用程序服务器的Web服务器的确是需要

配置与调整来达到最优化的设置。Web服务器关键的配置变更是指现在在一个设置中，这个

设置限定Web服务器与应用程序服务器启动是并发的连接与线程的数量。这个设置被设置得

相对比较低（50个线程），以保证对引入Web服务器的请求排队，同时保证应用程序服务器

引擎中的队列十分小。设置的调节务必与应用程序服务器本身线程的调节一致，而这一过程

是相当复杂的。但是最终这个设置能够保证应用程序服务器引擎本身在大量的请求压力下永

远也不可能瘫痪，这样就会运行得更加可靠。假如Web服务器的配置同意太多的用户同时连

接，那么吞吐量将随着应用程序服务器的不稳固而显著二降。即使是通过了这样的大量的调

节后，在Web应用与分布式事务基准中，J2EE应用程序服务器B性能仍然不能像J2EE应用程

序服务器那么好。与JTA分布式事务协作（这一特性在两个基准的测试中都被激活）性能差

是一个要紧的因素，这就需要使用1.3JRE代替1.4JRE。

JDBC驱动器的选择需要基于下列标准：

I特性的有用性：对事务的支持与可滚动的结果设置

整体性能

一共测试了四种驱动器：数据库提供者的驱动器（Oracle）、应用程序服务器提供者的

驱动器与两个领先的第三方驱动器提供者。在排除掉那些没有必备特征的驱动器后，剩下的

驱动器在负载下作了性能与稳固性测试。在决定使用JRE与JDBC驱动器后，应用程序服务

器同时作了应用程序服务器参数与Java运行时间参数协调。除了协调额外的服务器实例外，

通过在应用程序服务器引擎上运行多个服务器进程使得性能得到了很大的提高，应用程序服

务器引擎使用DNS在服务器实例间平衡负载。这种配置对两个应用程序服务器的大部分都是

最理想的，由于它同意使用服务器上所有的内存，然而，每一个兼容产品务必单独使用更少

的内存用于碎片收集，这就意味着周期性的碎片收集将会更加快速，减少进程相应的暂停时

间。

Web应用程序基准测试

该平台包含两个脚木，比重各占一半，一个脚木用以模拟用户简单的浏览网址，另一

个则模拟从网站寻找与购物。在只有浏览功能的脚本中，用户需要如下操作：

1.登录网站主页；

2.对100（）种产品进行三次任意的文字查询，在每次查询结果的网页上，单击“下一步”

按钮；

3.在某种范围内检验产品，重复三次；

4.对某种产品具体内容检验三次（包含产品存货纪录的实时读取）；

关于具有浏览与查询功能的脚本，模拟用户需要：

5.对1000种产品进行两次任意的文字查询，在每次查询结果的网页上，单击“下♦步”

按钮；

6.利用100,000个用户中的任意ID,在网站注册;

7.在购物车中添加50000个中的两个项目；

8.检验，确认账户信息，然后根据购物车中的项目下订单；

9.有一半时间用户用于退出操作，而一半时间不是这样，因此，50%的活动被关闭，

同时放弃这50%时间使得应用程序服务器能够处理关闭操作，关闭时间设定为10

分钟，即假如10分钟内没有任何操作，则关闭之。这种做法是真正的电子商务网站

对现实活动的合理模拟。

10.购物完成后,执行最后一次文字检索。

测试方法

对每种产品进行测试都包含两个完全独立的方法，一种是关闭图像下载功能，另一种

是开通图像下载功能（客户端具有浏览器缓存）。这么做是为了更全面的熟悉应用程序服务

器性能，该性能包含两个方面.，一个是终端处理情景，应用程序服务器本身不为PetStore

站点图像提供服务；另一个是通常情况处理情景，应用程序服务器处理程序逻辑，同时提供

下载图片到浏览器的功能,注意，.NETPetShop与MiddlewareJ2EEPetStore在其运行过程

中使用不一致的图像。因此，就图像而言，.NETPctShop务必加以修正，才能打开J2EEPet

Store图片，这样每种测试产品的图像数量与图像尺寸就相同了。

另外，利用模拟浏览器缓存下载图片时，程序设置已经被固定，因此在用户不断使用

过程中，对每个用户而言，同一图片只能被下载一次，这类似于浏览器缓存确保图片区速度

原因而在客户端存储的实际设置因此，网页中的普通图片，比如导航条，每个用户只能下

载一次，即便他作为一个模拟用户在脚本执行过程中访问多张网页。但是每个模拟用户的浏

览器缓存都是事先固定的，因而他们务必各自重定义自己的图像缓存。

这些测试是在2个，4个与8个CPU配置上运行的，目的在于熟悉当系统增加CPU时

应用程序服务器功能的垂直变化。关于每个数据点，其数据运行由数据激增，平稳，数据收

集与数据量减小这几个部分构成。从每个数据运行••小时的综合结果来看，只有当系统达到

稳固状态时才开始数据收集.对单个产品而言，直到用户登录的响应时间达到3秒或者者更

大的时候，数据点才被获取，由于每个产品假如在这些用户登录数以上进行测试通常出错。

因此那些功能扩展到承受更大用户量的产品才能够收集更多数据点。

Web应用程序结果（关闭图片下载功能）

图4：吞吐量峰值

WobApplicationBenchmark(noimages)

PeakThroughput

J2EEApplcatMJ2EEAppltcationNET1GW2KNET

SeiverAServerB11WmdowtNET

图5：网页平均响应时间为3秒时的最大支持用户数

WebApplicationBenchmark(noimages)

MaximumUserLoad

图6：双CPU应用程序服务器的吞吐量曲线

firc^MOdtfMu4。dcvtt—X0W1

2C，U“83。。”0・

图7：4CPU应用程序服务器的吞吐晟曲线

图8：8CPU应用程序服务器的吞吐量曲线

Web应用程序结果（启动图片下载功能）

图9：吞吐量峰值

W«bApphcationBenchmark(kmag«downloadon)

P«akThroughput

图1()：网页平均响应时间为3秒时的最大支持用户数

图12：4CPU应用程序服务器的吞吐量曲线

24小时分布式基准

设计分布式处理平台的脚本是为了全面测试服务器处理大量分布式处理登录的能力，

本文的测试对象则是编写命令。该脚本利用模拟用户进旺如下操作：

1.从10万个有效用户名中任选一个，填写资料登录网站；

2.从5万个项目任选一个加入购物车，同时立即订购，每登录一次则如此操作100次。因

此关于每次登录，检验程序就需要运行100次，包含验证账户信息与根据购物车（一个

分布式处理系统）的内容处理订单；

3.退出。

需要注意的是本测试中实际分布式处理事务与总的系统请求比率为1：5,由于服务器

的检验程序是一个5步骤、5页面的订单确认/订单处理程序。

该分布式处理平台运行在4CPU程序服务器上，用户登录数量达到最大值，所测试的

每个程序服务器产品，其持续吞吐量如卜.表所述：

图14：分布式处理平台测试结果

最大用户登录每秒钟分布式处理价格/性能1

程序服务器吞吐量事务所下订单

J2EEApplication

ServerA4.00059TPS$1,305

J2EEApplication1.00018TPS2（不能支持，$4,722（见注释2）

ServerB见脚注）

.NET4.00079TPS$468

l.O/WINDOWS

2000

.NET6000117TPS$3163

LlAVindows.NET

Server2003

1参见附录2,应用程序服务器系统硬件/软件总表

2J2EE应用程序服务器B不能在分布式处理平台连续2个小时支持最大用户负荷。它也不能

连续4个小时支持任何吞吐量，超出这个时间将会出现错误。

3估计值，根据Windows2（X）0AdvancedServer价格。Windows.NETServer2003价格未公布。

图15：用MeivuiyLoadRunner分析（J2EE应用程序服务器X运行结果，显示24小时的吞吐量。

该图描述连续24小时Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第

二部分处理事务的验证量。

・_F905*.■川1id0•/酷C10*，I，I—.2rt.“93i:x：x

注意：前6个小时吞吐量略有下降，而后TPS则稳固在24小时的平均处理水平59个命令/每秒。

图16：用Me心ryLoadRunner分析\J2EE应用程序服务器B运行结果，品.示了24小时的吞吐量。

该图描述连续24小时Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第

二部分处理事务的验证量。

Or

O7

I*tIt

9lt7

:2»

OlHio

0oo

Omoa

Oaa

O3oo

Ooa

Ooa

O2oo

Oox

Ooa

■IJIISi・»<awr，A二七：“'I

注意：分布式处理平台的峥值乔吐a不能持续2小时以匕对参数做各类调整进行四十多次

测试说明，J2EE应用的服务题处理数据库的分布式XA兼容处理有明显难度。以上测试

具有代表性的，TPS略有下降，继而是急剧下降，上升，而后是程序服务器失败，以至于4

小时以上不能成功处理请求。

图17：JIJMercuryLoadRiumer分析Microsoft.NET1.0/Windows2000

Se/w/•运行结果，显示了24小时的吞吐晟。该图描述连续24小时Web请求每秒钟事务处理最。

注意，实际订单操作（分布式处理）是笫一部分处理事务的验证量。

注意：吞吐量24小时持续稳固，24小时平均命令处理的TPS是79个/秒。

图18：用LoadRimner分析Microsoft.NET1.1/Windows.NET

Se/wr2003运行结果，显示了24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处

理量。注意，实际订单操作（分布式处理）是第二部分处理事务的验证量。

“3

IME

2

11MIX

注意：吞吐量24小时持续稳固，24小时平均命令处理的TPS是117个/秒。

Web服务基准

由于Web服务作为应用程序服务器的一项新领域已经被广泛的推出，因此新的PetStore

基准的犷展功能就是用来检验一个原型Web服务的每一个应用程序服务器的性能。由于Web

服务自身的规定，因此它能够提供现实的测试实例来证明应用程序服务器的性能，以通过

SOAP激活基本目标与将简单与复杂数据类型/对象串行化为XML文件的性能。PelStore中的

Web服务的功能就是将单个输入参数作为-个定单ID,然后执行在数据库中寻找这个定单的

动作，最后将定单对象作为XML文件返回给调用程序。定单对象本身既包含简单数据类型

（字符串、整数型、小数型）也包含数组（代表某个条可全面的排列项）。

图19.从基于SOAPL1的Neb服务调用返回定单对象的基本XML模式

<GetOrderResult>

<orderld>int</orderld>

<date>dateTime</date>

<userld>string</userld>

<cardType>string</cardType>

<cardNumber>String</cardNumber>

<cardExpiration>string</cardExpiration>

<billingAddress>

<firstName>String</firstName>

<lastName>string</lastName>

<addressl>string</addressl>

<address2>string</address2>

<city>string</city>

<state>string</state>

<zip>string</zip>

<country>string</country>

<phone>String</phone>

</billingAddress>

<shippingAddress>

<firstName>String</firstName>

<lastName>string</lastName>

<addressl>String</addressl>

<address2>string</address2>

<city>string</city>

<state>string</state>

<zip>string</zip>

<country>String</country>

<phone>string</phone>

</shippingAddres3>

<lineltems>

<item>

<id>string</id>

<line>int</line>

<quantity>int</quantity>

<price>decimal</price>

</item>

<item>

<id>strlng</id>

<line>int</line>

<quantity>int</quantity>

<price>decimal</price>

</item>

</lineItems>

</GetOrderResult>

在第一种方案中，客户端将会发送一条SOAP请求，要求在返回的定单对象中包含10000

条可能的定单中随意的一条，而每条定单都包含有5个重复的行条目。这一测试对提供Web

服务的单个应用程序服务器产生了很大的压力，这样设计的目的是为了验证应用程序服务器

作为•个Web服务主机工作的性能与从成千上万的并发用户总提供SOAP请求服务的能力。

Web服务基准—直接Web服务请求

图20.峰值吞吐最

图21.最大用户负载•平均页面响应阈值3秒

022.2CPU应用程序服务器的吞吐量曲线

Tbr&jghpotSOAPWebServiceCM

2CPUApplKJbonServer

图23.4CPU应用程序服务器的吞吐量曲线

图24.8CPU应用程序服务器的存吐量曲线

WEB服务基准—远程SOAP客户端请求

图25.峰值吞吐量

WebSecvictviaProxytoRemoteWSHost

PeakThroughput

观察结果:在J2EE应用程序服务器A与B上,SCPUWeb服务主机在大约200TPS下达到CPU饱

与状态,因此,8CPU与4CPU\%b服务器客户端配置相比，吞吐量几乎没有任何的改善。

在Microsoft.NET（包含Windows2000与Windows.NET服务器）上,Web服务主机在Web服务

客户端计算机达到饱与之前并没有达到饱与,因此8CPU与4CPUSeb服务器客户端配置相

比,能够提高吞吐量。

图26.最大用户负载•平均页面响应阈值3秒

图27.2CPU应用程疗服务器的吞吐量曲线

Throughp<.tRemoteSOAPCMvuProxyObject

2CPUApplicabonServer

UbwsflHxc。*tteAhttm|

图28.4CPU应用程序服务器的吞吐量曲线

ThroughpMRemoteSOAP0ProxyOt)|ect

4CPUApphcjbonServer

图29.WCPU应用程序服务器的存吐量曲线

ThroughputRemoteSOAPCMviaProxyObject

8CRUApplicabonS4rvet

附录1——代码行对比

Middleware公司的JavaPelStore2.0实现使用的了与原始的JavaPetStore（除了对性能进

行充分的优化外）相同的基础EJB推荐的体系结构。因比，其代码行的数量与原先的14004

行的代码相比，并没有很大的改变。而关于.NETPetSh叩2.0实现，Microsoft则做了更进一

步的优化以减少总代码行数，同时也扩展了一些为分布式事务与Web服务服务的新特征。新

的.NETPetShop2.0一共有2096行C#代码（在1.5版本中一共有3484行代码，新的版本减少了

40%）。.NET与J2EE的版本都是完全的面向对象的，都是对UI层、中间层与数据层应用程

序逻辑进行分离的n层逻辑结构。完全代码细目分类如下：

图30.不一致实现中不一致代码行的列表描述

Element.NETPetShop2.0MiddlewareJ2EEPet

Store2.0

UserInterface1,0025.567

MiddleTier795