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

Middleware公司
J2EE和.NET 应用程序服务器与Web服务基准比较
Middleware公司，2002年10月

Middleware公司简介

Middleware公司致力于提供先进的企业Java技术培训与咨询服务。公司成立于1998年，其宗旨是帮助企业向Java平台转移来促进电子商务项目的成功。公司协助世界上一些最大型的机构例如BEA、Oracle、Cisco、Nextel、MetLife、Sterling Commerce、Standard&Poors以及许多其它企业在Java专家的指导下熟练掌握平台，减少风险，维持成本效益。这些专家都是有着雄厚的开发经验以及强大的服务器方面技术的资深工程师，同时他们还是该领域著名的带头人。公司的服务包括Java2、EJB、J2EE和XML-Web服务的现场培训，体系结构咨询以及遍布世界课程培训。这些课程在北美以外的地方都拿到了课件许可证。Middleware 公司同时创建了网站TheServerS并一直维护着该网站，这个网站是目前领先的在线J2EE社区。
© 2002 Middleware公司

目录表
序言
比较是公正的吗？
修订过的Java Pet Store
利用新的企业功能扩充Pet Store.
改进的Java Pet Store应用程序
改进后的.NET Pet Store2.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 .NET 1.0/WINDOWS 2000 服务器协调
基本全局变量的修改：
Web基准
分布式事务基准
Web服务基准
附录8——.NET 1.1/WINDOWS.NET 服务器2003协调
基本全局配置的改变：
Web基准
分布式事务基准
Web服务基准

序言
2001年5月，Sun微系统®将JavaTM Pet Store作为基于J2EETM的Web应用程序的示范实现推出。Sun公司宣布，Java Pet Store应用程序阐述了一些最好的J2EE开发经验，为客户在创建他们自己企业的Web应用程序时提供了一个可参考的设计模型。Sun公司在 Pet Store网址的维护。Java Pet Store 是众多领先的J2EE应用程序服务器中的一个基础的例子。
2001年11月，Microsoft® 宣布它已经利用Microsoft .NET Framework和C#重新实现了Java Pet Store，以此来表明.NET平台相对于J2EE的优越性。.NET Pet Shop与Sun Java Pet Store功能上是相同的，但它是利用Microsoft改进的体系结构创建的，这个体系结构是为基于ASP.NET和.NET通用语言运行时（CLR）的n层Web应用程序开发的。Microsoft已经发布了.NET Pet Shop的基准信息，以此来表明在高用户负载下，.NET Pet Shop在性能上比Java同类产品有明显的提高。这一基准比较的结果是基于对.NET Pet Shop性能与Oracle®-发表的运行在Oracle9iAS上的Java Pet Store基准性能的比较。最新的基于.NET Pet Shop1.5的比较可以从下面的网址获得： IBM®和Oracle坚持认为目前的比较并没有实际意义，因为Sun的Pet Shop应用程序蓝图还没有进行性能优化，因此并不表示它就是基准。
这篇报告包含了由Middleware公司得出的基于Java Pet Store最新实现的一系列广泛的新基准结果。这一新的实现在性能和伸缩性上都作了广泛的优化，测试是在两台先进的、市面上可以买得到的J2EE应用程序服务器上进行的。新的实现同时还扩展到支持两个物理数据库之间分布式适应XA事务。此外，实现中还增添了一项基于XML的Web服务和Web服务客户程序。为了基准的比较，Microsoft也已经向Middleware公司提供了相应功能的修订过的.NET Pet Shop 2.0应用程序，该应用程序遵循相同的规范，并且Middleware已经完成了对它的审查工作。这个实现包括通过由COM+服务的.NET组件支持分布式事务；同时具有修订的J2EE实现中相应的Web服务功能。本文详细阐述两种新实现的性能与伸缩性广泛基准的比较结果。

比较是公正的吗？
从最初开始，许多Java开发者坚持认为原始的比较是无效的，因为Sun的版本在开发效率和性能上都没有进行优化。Java开发者指出，Microsoft实现经过了专门的性能优化，并且与Sun的版本使用的是不同的体系结构。例如，Java开发者指出Microsoft在他们的实现中使用SQL服务器贮存程序（Sun的Java版本使用的是动态SQL，这样使得数据库移动更加方便），这是这两种不同实现的关键区别，这一区别使得.NET版本比Java同类产品运行更加快速。对于这一点，Microsoft坚持认为Sun的应用程序是被作为一个J2EE企业设计最佳实践模板推出的，因此，完全有理由认为应用程序在可伸缩性已经作过了相当好的调整。Microsoft指出它也采用类似的方法将所有.NET Pet Shop源代码作为.NET企业设计模板的最好实践发布；它使用贮存程序的原因基于这样的一个事实，那就是许多的企业DBA为了控制的方便更趋向于将查询封装在贮存程序，同时许多人甚至不接受在应用程序中的动态SQL。然而，网上的Java开发者例如TheServerS却提出了合法性的问题，例如：
● 难道J2EE版本不能够重新编写，对其进行优化以实现更好的性能？
● 如果.NET版本不使用贮存程序，而是使用与J2EE版本里相同的动态SQL，那么其性能会发生什么变化呢？
● 对比是否可信？尽管原始的比较使用的硬件是类似的，但并不是相同的，并且比较是由Oracle和Microsoft各自的实验室完成的，使用的是不同版本的Mercury LoadRunner负载测试软件和不同的测试台。

修订过的Java Pet Store
精通基于Web的J2EE应用程序服务器的Middleware公司，根据Java社区的反馈信息以及企业开发者公布在TheServerSide上的反馈信息，使用J2EE和EJB从新创建了Java Pet Store，对其性能进行了充分的优化，确保新的实现仅仅包含执行应用程序所需要的代码，而没有那些只是用来表明J2EE特征的代码。同时Middleware公司将Pet Store应用程序的功能扩展到支持重要的新的企业功能，这些功能包括分布式、适应XA事务以及基于XML的Web服务。这一新的应用程序已经被作为Middleware的Java Pet Store 2.0公布在TheServerSide上。同时Microsoft也将他们的.NET Pet Shop升级到2.0版，增添了支持分布式事务与Web服务的功能，在.NET应用程序中使用所有的动态SQL来代替贮存程序。Microsoft已经将这个新的.NET Pet Shop 2.0版本发布在MSDN上，供.NET开发者在创建他们自己的n层Web应用程序的时候作为一个蓝图使用，同时Microsoft也在ServerSide上公布了源代码。
Middleware公司在新的实现中完成了一系列广泛的基准，使用的是与应用程序服务器和数据库后端系统相同的硬件，并且采用了相同的测试台。本文包括了这些有Middleware公司执行并且验证的测试的结果。这些测试包括广泛的J2EE应用程序服务器协调与优化，都是在2002年6月到9月的四个月的时间内进行的。
Middleware公司颁布的基准的基本规则包括：
1. J2EE与.NET实现在功能上必须100%的相同，在行为上没有任何的区别。
2. 两个实现都必须是根据最佳实践代码准则创建的，这样现实中的消费者在创建他们自己的应用的时候可以遵循每一项有效设计模式服务。
3. 每一个应用程序在逻辑上都必须是三层实现，使用分割好的组件来封装中间层商业和数据访问逻辑。
4. 应用程序必须设计得使它们都能够跨多中间层应用程序服务器群集来缩小。
5. 基准必须与能够响应现实世界产品配置的现实的应用程序服务器和数据库配置设置一起运行。
6. 所有的基准应用程序源代码、数据负载以及测试脚本（包括.NET和J2EE）都必须公布在S上，这样客户可以复制并验证其结果。在基准中使用的源代码、数据库结构以及测试脚本可以从下面的网得到： 。

利用新的企业功能扩充Pet Store.
为了使新的基准更加易于充分理解，J2EE和.NET中的Pet Store 2.0应用程序需要扩展重要的新的企业功能，其中包括：
● 分布式事务。在原始的Sun的Java Pet Store中，所有的数据库事务都发生在单个的数据库中，而在Pet Store 2.0基准中，对于每一条命令，都有一项分布式的事务在两个不同的物理数据库之间执行，命令信息放在一个数据库中，而存货统计在另外一个数据库中进行。如果事务中有任何一部分失败，那么整个事务就会再从头开始。创建这样的应用程序与基准的目的是对使用JTA事务服务的J2EE EJB与通过利用COM+事务的.NET服务处理的.NET事务的性能进行对比。
● Web 服务。Pet Store 2.0包含有一项以XML格式提供命令信息的Web服务，这些信息包括所有命令的详细内容和每一条特殊命令的排列项。Web服务在SOAP1.1上工作。除了Web服务本身外，Pet Store 2.0还包含一个用来调用Web服务在浏览器中显示结果的简单的客户程序包。

改进的Java Pet Store应用程序
Java Pet Store应用程序通过许多途径来改进增加其性能。修订后的应用程序仍然保持具有EJB基础的设计模式，类似由J2EE升级而成的可缩放n层企业应用程序。然而，许多性能上的改进对应用程序进行了彻底的性能优化，下面将详细的介绍这些性能的优化。

● 事务边界的改进：尽管大部分原始的Pet Store应用程序遵循应用程序的标准访问模式，调用一个EJB会话，这样完成一个事务就需要调用所有需要的EJB实体。改进后这种方法并没有在所有的情况下延续，因为它会导致原始的实施中某些性能的退步。例如，在某一类别所包含的产品报表中，三种各包含有三列的产品需要九次事务才能完成，而不是一次。在改进后的Middle Java Pet Store 2.0中 ，所有的事务边界都被修改以最小化事务次数
● 为EJB实体实现了一种Read-Mostly模式：在原始的Pet Store中，所有的实体都是读写式。这种模式开发简单，但是效率低下，因为每一次操作都会导致读写数据库一次，即便是对静态数据的操作也是如此。为了减轻这个问题的影响，有些适当的实体块被以一种Read-Mostly的模式重新实现。在这种模式中，EJB实体被分成两个部分：一部分为只读模式，其状态保存在事务边界中，另一部分为写模式；两部分实体都分享一个引用，这个引用指向代表它们的数据的通用数据结构。只读实体块界面包含有访问方法，而写实体块界面包含有改变方法；所有的数据库读的方法都包含在只读模式EJB中，例如 ejbLoad()，所有的写数据库方法都包含在写模式EJB中，例如ejbStore()。此外，在整个实体中添加了isModified()方法，该方法可以写入数据库这样所有不必要的数据库更新都可以避免。
● 改进了数据库索引的使用：改进后在一般的搜索方面都可以使用索引，例如搜索产品的名字以及样品ID。此外，原始Pet Store的表格生成脚本中的一个主要关键字被忽略了，而这个关键字往往使得详细目录的访问非常的慢。
● 去掉多余的JNDI查找和调用初始化：每一个数据资源与EJB原参考都储存在应用程序服务器的JNDI服务中。在原始的Pet Store中，每次在这些参考被使用的时候，系统都要找出JNDI初始背景，然后在JNDI中查找相应的参考。两者都仅仅只需要做一次就可以了。代码的改变使得所有不必要的JNDI调用都省去了。
● 动态类只有一次初始化：在Pet Store中使用的一种在编译的时候载入不知名的类的设计模式就是用来显示Java的灵活性的。它通过查找将要作为字符串使用的类的名字，使用forName()操作来为该类生成实例来完成。然而，进程的灵活性的代价就是执行上的高耗费。那些类的名字在编译时已经知道的情况下，程序将这一过程移除同时类的名字被编码。在其余的情况下，程序确保类的查找和确定只执行一次，然后只有在此类生成新的实例的时候再次执行。

就像前面提到的一样，还有许多其他的改进：包括广泛的使用JDBC预定义的语句，对字符串处理的重大改变以及其它的重大改进。然而，上面详细列出的这些改变带了了性能上的最大的改观。基于J2EE应用程序服务器A比较性的性能数据，与Sun公司最初实施的Java Pet Store相比，这些优化大致对性能提高了17倍。这一数据是根据对进行性能平衡（对分布式事务的支持，数据的高速缓存）后原始Sun Java Pet Store与新的Middleware J2EE Pet Store 2.0的比较得出的。新的实施与旧的实施相比，性能上的提高见下表：

图1.原始的Sun Java Pet Store与优化后的EJB Java Pet Store 2.0峰值吞吐量的比较

改进后的.NET Pet Store2.0
和Java Pet Store类似，.NET Pet Shop 2.0的体系结构是由Microsoft推出的3层逻辑结构，其目的是为了创建基于.NET的可缩放的企业应用程序。然而，在某些关键的地方，代码基础已经作了最新的改进，同时做了性能上的提高。
最主要的改变包括：
1. 对于所有的数据库访问，使用动态SQL代替贮存程序。这样就消除了关于性能的提高是通过加入编译过的贮存程序，牺牲了数据库的轻便实现的争论。
2. 在命令布置中使用了分布式事务。
3. 使用一种基于SOAP的Web服务来返回命令的详细信息以及调用客户页面。
4. 使用数据转发器控制代替数据栅格控制来提高性能。
5. 使用简单的数据高速缓冲存储器在中间层数据缓冲存储器中缓冲静态只读产品信息。
新的.NET Pet Shop 2.0以及其完全体系结构白皮书可以从下面的网址下载：

新的实现的比较
改进后的Java Pet Store实现仍然保持忠实于Sun微系统发布的Model-View-Controller体系结构，充分利用包括会话块与实体块的J2EE核心特征的优势。在对软件进行上面详细列出的为优化性能而做出的广泛修改的同时，软件方面由Sun微系统推荐的基本设计模式以及广泛应用的面向对象的开发方式仍然保持完整无缺。这一体系结构使得用户界面与中间层商业逻辑以及数据访问逻辑完全分离，后端进程被封装在不同的EJB中。类似的，.NET Pet Shop 2.0也采用了完全面向对象的n层体系结构，为中间层和数据访问目标实施了C#类。这样它就实现了通过使用ASP.NET Web表单将UI与中间层商业逻辑完全的分开，而ASP.NET Web表单则通过使用一种code-behind模式（服务器端的代码通过封装与客户端HTML分开）将HTML和客户端单元与服务器端进程单元完全分开。Web表单模式利用了框架中提供的ASP.NET服务器控制的优势，为大部分的UI/外观单元服务，例如列表，网格等。反过来，服务器控制激活用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秒的缓冲时间，这就意味着与新的基准相比，在相同用户负载量的情况下，服务器所承受的压力只有一半）。页面输出高速缓冲存储也被停止，这样保证服务器必须处理收到的每一条请求。不同用户负载量下的数据点都被单独的测量，同时测量ramp-up、settledown、数据收集和ramp down时间来测定结果的精确性（每一个单独数据点的总执行时间都超过1小时）。为了得到更多的信息，这套基准以两种不同的方式执行：
a. 关闭图片下载：这样只有基本应用程序服务器引擎被使用到。这一测试可以显示产品操作包括服务器端脚本、会话状态管理、对象激活以及数据库连通性在内的应用程序逻辑的良好程度。
b. 打开图片下载：模拟一个浏览器高速缓冲存储器这样，每个访问站点的用户在一次脚本重复期内都需要下载每一张单独的图片一次。这一测试可以显示应用程序服务器作为Web服务器/应用程序服务器的综合工作的合适程度。
注意，这一基准的结果不能与过去Oracle and Microsoft公布的Pet Shop的基准数据比较，因为使用了不同的测试脚本和缓冲时间，同时在应用程序的某些功能方面也与原始的Pet Shop基准有差别。
24小时分布式事务基准
设计这一基准的目的是为了对每一个测试产品的分布式事务执行能力进行测试。测试脚本包括用户登录、然后单独的处理一条100条项目的命令。命令中每一条项目结帐过程的完成包括这个过程的最后一步就是用来激活一次分布式事务的命令的实际布置，脚本的最后是退出。每一个用户在一个用户会话中都会完成100次单独的分布式事务。测试会在每一个产品能够产生峰值吞吐量的用户负载下运行，并且持续24小时来观察这种吞吐量是否可持续。

价格性能度量
除了绝对性能度量外，每个产品基于4-CPU配置在24小时的运行中的价格度量也被计算出来了。这一度量是以每次事务每秒花费的美元数来计算的。花费包括中间层的硬件的开销、应用程序服务器软件许可证开销（以4-CPU配置的每个产品的发布价格来计算）再加上用于应用程序服务器的操作系统的购买价格。价格度量中没有包括数据库许可证费以及接下来的支持维护费用。
Web服务基准
这一基准测量为J2EE和.NET服务的Web服务的性能特征。测试包括两个基本的配置：
a. Web服务的直接激活 使用100台分布式的物理计算机，每一台模拟多用户生成直接SOAP调用来激活Web服务。这一基准测试应用程序服务器处理SOAP请求的能力以及作为Web服务提供者的能力。
b. Web服务的远程激活 应用程序服务器通过一个代理对象。在这种配置下，一共配置两台物理的应用程序服务器，一台作为一个远程Web服务提供者（就像测试a中的那样）做工，另外一台作为Web服务客户端而工作。100台物理客户端计算机向应用程序服务器计算机发送HTTP/HTML请求形成负载，应用程序服务器计算机接着向Web服务提供者计算机发送SOAP请求。设计这一测试的目的是测试应用程序服务器Web服务客户端性能以及发送基于对象激活的远程SOAP的性能。
测试实验室与测试软件
由Mercury交互式代表在实验室里安装和配置Mercury LoadRunner 7.5。测试是在大规模的实验室里进行的，这种实验室包含有100台客户端计算机，能够在保证客户端在系统中不成为瓶颈的同时产生高同步性的用户负载。实验室采用CISCO吉比特主干线，每台服务器配置两个吉比特网卡，每一个网卡包含50个客户端子集。这样配置的目的是为了保证在测试的过程中Web不会成为瓶颈。在吉比特Web中同时还配置了两台单独的数据库服务器。应用程序服务器测试在Compaq ProLiant 8500 服务器上运行，分别配有2、4、8个8550MHz的CUP和2GB的RAM（对2CPU和4CPU设置）以及4GB的RAM（对8CPU设置）。两个数据库也是Compaq ProLiant 8500服务器，每台服务器使用8550MHz的CPU以及3GB的RAM，同时增加了光纤光学控制器来加速Compaq RAID存储队列。数据库、客户端和Web利用在测试过程中都被监控以保证这些设备不会成为瓶颈。在所有的J2EE和.NET的实例中，测试会精确的报告用于应用程序测试的应用程序服务器软件本身的能力。

图2.基础Web应用程序基准、24小时分布式事务基准以及Web服务直接SOAP激活基准测试的实验室布置。

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

产品测试
Microsoft .NET
对于.NET产品，Middleware公司测量的是其商业发布的运行在Windows 2000下的.NET Framework 1.0 (SP2)以及在Windows.NET Sever 2003的RC Build 3681上创建4322.508的.NET Framework 1.1 RC。在测试中作为后端使用的是Microsoft SQL服务器2000数据库。.NET 1.0 and .NET 1.1在配置上的精确优化在附录7.8中给出。
测试前.NET协调以及优化配置需要的时间.
在开发出.NET Pet Shop 2.0后（这个应用程序实际上是由一家设立在California的Microsoft解决方案提供者开发成功的），一个Microsoft员工花了大约2个星期的时间试运行，在Middleware公司测试前（单人2周的工作量）对程序进行包括配置设置方面的优化。
.NET协调与优化配置.
优化就是在.NET Framework 设置的基础上作些微小的变化。优化包括：
1．确保数据库正确的协调，拥有足够的存储空间来为24小时事务的沉重运载量分配存储空间。
2．对基础ASP.NET设置作了修改，使得表单认证可以与基于Windows的认证对比，因为应用程序本身是一个能够通过任何拥有标准窗口的客户端平台访问的稀少客户应用程序（认证是以一个记录有用户名和密码的数据库为基础的）。
3．将ASP.NET工作器和IO线程从25个（Windows2000的缺省设置）下调到20个；微小的上调在Web服务运行期间每一个客户端IP被允许的Web连接的数量来保证服务器允许每个负载生成客户端可以激活足够多的向.NET应用程序服务器的同步Web连接。
4．在Windows2000的测试中，设置ASP.NET进程模式以便.NET应用程序可以运行在与IIS Web服务器一样的进程空间。
5．在Windows.NET Server 2003的测试中，使用了新的IIS 6.0进程模式（缺省设置），因为这样可以产生比Windows2000更好的性能，同时允许应用程序在与HTTP服务器分离的指定的服务器进程（应用程序存储池）中运行。
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 9i后端数据库，因为这种数据库是每种产品首推使用的数据库，拥有完整的J2EE/JDBC应用程序服务器特征的支持。两个应用程序服务器都在RedHat Linux 7.2和Windows 2000 Advanced Server (SP2)进行了测试。Middleware对两个应用程序在不同的操作系统下运行作了比较，最后使用能够为应用程序服务器提供最佳性能的操作系统的测试结果来公布。对于J2EE应用程序服务器A来说，采用Windows 2000操作系统因为在该系统下这个应用程序服务器的性能明显的好于在Linux 7.2操作系统下；而对于J2EE应用程序服务器B来说，在Windows 2000和Linux 7.2系统下性能相似，但是测试中还是选择了Windows 2000主要是因为在这一系统下更容易监督计算机在有负载的情况下的性能特征，而不必再使用嵌入的Windows 2000性能监督器以至影响其性能。J2EE应用程序服务器A和J2EE应用程序服务器B精确配置优化在附录5-6中给出。

测试前J2EE协调以及优化配置需要的时间.
在J2EE优化后的应用程序开发成功后，两个有经验的Middleware公司的员工（全天）在进行最后的数据点测量前（单人10周的工作量），花了将近5个星期的时间为J2EE应用程序服务器A协调以及优化配置。同时还花了将近5个星期的时间为J2EE应用程序服务器B（单人10周的工作量）协调以及优化配置。对两台J2EE应用程序服务器的调整和优化配置过程是非常重要的，下面将会详细的讲解。
J2EE协调与优化配置
J2EE应用程序由Middleware专家根据最有经验的销售者的指导对测试的不同的应用程序服务器产品分别作了广泛的协调。协调包括用不同的Java Runtime Environment (JRE)以及数据库驱动程序检测产品以得到最优组合；以及基本应用程序服务器设置优化，例如堆阵规模、高速缓冲存储块以及线程设置。

在对两个应用程序服务器的协调过程中，首先考虑到的是将要使用的Java Runtime Environment (JRE)和JDBC驱动器的选择。这里，一共测试了四种JRE：SunSoft 1.3和1.4、 JRockit 3.1以及IBM 1.3。

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

然而J2EE应用程序服务器B不与SunSoft JVM 1.4兼容，因此，只能够使用SunSoft JVM 1.3。这个JVM能够为J2EE应用程序服务器B提供最佳的优化性能，尽管与SunSoft JVM 1.4相比，碎片收集仍然存在缺陷。结果发现，应用程序服务器B通过使用应用程序服务器的前后Web服务（一个单独运行的进程）来调节引入到应用程序服务器本身的请求可以获得更可靠的性能。这是由销售者B为他们的应用程序服务器推荐的实际经验。通过适当的调节引入到应用程序服务器的并发请求的数目可以使得服务器在相同的负载情况下运行更加快速与可靠，同时也可以把碎片收集的影响最小化。使用应用程序服务器的Web服务器的确是需要配置与调整来达到最优化的设置。Web服务器关键的配置变更是指现在在一个设置中，这个设置限定Web服务器与应用程序服务器启动是并发的连接与线程的数量。这个设置被设置得相对比较低（50个线程），以保证对引入Web服务器的请求排队，同时保证应用程序服务器引擎中的队列十分小。设置的调节必须与应用程序服务器本身线程的调节一致，而这一过程是相当复杂的。但是最终这个设置能够保证应用程序服务器引擎本身在大量的请求压力下永远也不会瘫痪，这样就会运行得更加可靠。如果Web服务器的配置允许太多的用户同时连接，那么吞吐量将随着应用程序服务器的不稳定而显著下降。即使是经过了这样的大量的调节后，在Web应用和分布式事务基准中，J2EE应用程序服务器B性能仍然不能像J2EE应用程序服务器那么好。与JTA分布式事务协作（这一特性在两个基准的测试中都被激活）性能差是一个主要的因素，这就需要使用1.3JRE代替1.4JRE。

JDBC驱动器的选择需要基于以下标准：
1. 特性的实用性：对CA事务的支持以及可滚动的结果设置
2. 整体性能

一共测试了四种驱动器：数据库提供者的驱动器（Oracle）、应用程序服务器提供者的驱动器以及两个领先的第三方驱动器提供者。在排除掉那些没有必备特征的驱动器后，剩下的驱动器在负载下作了性能与稳定性测试。在决定采用JRE和JDBC驱动器后，应用程序服务器同时作了应用程序服务器参数和Java运行时间参数协调。除了协调额外的服务器实例外，通过在应用程序服务器引擎上运行多个服务器进程使得性能得到了很大的提高，应用程序服务器引擎使用DNS在服务器实例间平衡负载。这种配置对两个应用程序服务器的大部分都是最理想的，因为它允许使用服务器上所有的内存，然而，每一个兼容产品必须单独使用更少的内存用于碎片收集，这就意味着周期性的碎片收集将会更加快速，减少进程相应的暂停时间。

Web应用程序基准测试
该平台包含两个脚本，比重各占一半，一个脚本用以模拟用户简单的浏览网址，另一个则模拟从网站寻找以及购物。在只有浏览功能的脚本中，用户需要如下操作：
1． 登录网站主页；
2． 对1000种产品进行三次任意的文字查询，在每次查询结果的网页上，单击“下一步”按钮；
3． 在某种范围内检验产品，重复三次；
4． 对某种产品具体内容检验三次（包括产品存货纪录的实时读取）；

对于具有浏览和查询功能的脚本，模拟用户需要：
5． 对1000种产品进行两次任意的文字查询，在每次查询结果的网页上，单击“下一步”按钮；
6． 利用100，000个用户中的任意ID，在网站注册；
7． 在购物车中添加50000个中的两个项目；
8． 检验，确认账户信息，然后根据购物车中的项目下订单；
9． 有一半时间用户用于退出操作，而一半时间不是这样，于是，50%的活动被关闭，同时放弃这50%时间使得应用程序服务器可以处理关闭操作，关闭时间设定为10分钟，即如果10分钟内没有任何操作，则关闭之。这种做法是真正的电子商务网站对现实活动的合理模拟。
10． 购物完成后，执行最后一次文字检索。

测试方法
对每种产品进行测试都包含两个完全独立的方法，一种是关闭图像下载功能，另一种是开通图像下载功能（客户端具有浏览器缓存）。这么做是为了更全面的了解应用程序服务器性能，该性能包括两个方面，一个是终端处理情景，应用程序服务器本身不为Pet Store站点图像提供服务；另一个是一般情况处理情景，应用程序服务器处理程序逻辑，同时提供下载图片到浏览器的功能。注意，.NET Pet Shop和Middleware J2EE Pet Store在其运行过程中采用不同的图像。于是，就图像而言，.NET Pet Shop必须加以修正，才能打开J2EE Pet Store图片，这样每种测试产品的图像数量以及图像尺寸就相同了。

另外，利用模拟浏览器缓存下载图片时，程序设置已经被固定，因此在用户不断使用过程中，对每个用户而言，同一图片只能被下载一次，这类似于浏览器缓存确保图片因速度原因而在客户端存储的实际设置。于是，网页中的普通图片，例如导航条，每个用户只能下载一次，即便他作为一个模拟用户在脚本执行过程中访问多张网页。但是每个模拟用户的浏览器缓存都是事先固定的，因而他们必须各自重定义自己的图像缓存。

这些测试是在2个，4个以及8个CPU配置上运行的，目的在于了解当系统增加CPU时应用程序服务器功能的垂直变化。对于每个数据点，其数据运行由数据激增，平稳，数据收集以及数据量减小这几个部分组成。从每个数据运行一小时的综合结果来看，只