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

编号：时间：2021年x月x日书山有路勤为径，学海无涯苦作舟页码：第页Middleware公司J2EE和.NET应用程序服务器与Web服务基准比较Middleware公司，2002年10月Middleware公司简介Middleware公司致力于提供先进的企业Java技术培训与咨询服务。公司成立于1998年，其宗旨是帮助企业向Java平台转移来促进电子商务项目的成功。公司协助世界上一些最大型的机构例如BEA、Oracle、Cisco、Nextel、MetLife、SterlingCommerce、Standard&Poors以及许多其它企业在Java专家的指导下熟练掌握平台，减少风险，维持成本效益。这些专家都是有着雄厚的开发经验以及强大的服务器方面技术的资深工程师，同时他们还是该领域著名的带头人。公司的服务包括Java2、EJB、J2EE和XML-Web服务的现场培训，体系结构咨询以及遍布世界课程培训。这些课程在北美以外的地方都拿到了课件许可证。Middleware公司同时创建了网站TheServerS并一直维护着该网站，这个网站是目前领先的在线J2EE社区。©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/WINDOWS2000服务器协调 基本全局变量的修改： Web基准 分布式事务基准 Web服务基准 附录8——.NET1.1/WINDOWS.NET服务器2003协调 基本全局配置的改变： Web基准 分布式事务基准 Web服务基准

序言2001年5月，Sun微系统®将JavaTMPetStore作为基于J2EETM的Web应用程序的示范实现推出。Sun公司宣布，JavaPetStore应用程序阐述了一些最好的J2EE开发经验，为客户在创建他们自己企业的Web应用程序时提供了一个可参考的设计模型。Sun公司在/blueprints/上提供对一系列JavaPetStore网址的维护。JavaPetStore是众多领先的J2EE应用程序服务器中的一个基础的例子。2001年11月，Microsoft®宣布它已经利用Microsoft.NETFramework和C#重新实现了JavaPetStore，以此来表明.NET平台相对于J2EE的优越性。.NETPetShop与SunJavaPetStore功能上是相同的，但它是利用Microsoft改进的体系结构创建的，这个体系结构是为基于ASP.NET和.NET通用语言运行时（CLR）的n层Web应用程序开发的。Microsoft已经发布了.NETPetShop的基准信息，以此来表明在高用户负载下，.NETPetShop在性能上比Java同类产品有明显的提高。这一基准比较的结果是基于对.NETPetShop性能与Oracle®-发表的运行在Oracle9iAS上的JavaPetStore基准性能的比较。最新的基于.NETPetShop1.5的比较可以从下面的网址获得：/team/compare/veritest.aspx。然而，许多Java开发商以及Sun,IBM®和Oracle坚持认为目前的比较并没有实际意义，因为Sun的PetShop应用程序蓝图还没有进行性能优化，因此并不表示它就是基准。这篇报告包含了由Middleware公司得出的基于JavaPetStore最新实现的一系列广泛的新基准结果。这一新的实现在性能和伸缩性上都作了广泛的优化，测试是在两台先进的、市面上可以买得到的J2EE应用程序服务器上进行的。新的实现同时还扩展到支持两个物理数据库之间分布式适应XA事务。此外，实现中还增添了一项基于XML的Web服务和Web服务客户程序。为了基准的比较，Microsoft也已经向Middleware公司提供了相应功能的修订过的.NETPetShop2.0应用程序，该应用程序遵循相同的规范，并且Middleware已经完成了对它的审查工作。这个实现包括通过由COM+服务的.NET组件支持分布式事务；同时具有修订的J2EE实现中相应的Web服务功能。本文详细阐述两种新实现的性能与伸缩性广泛基准的比较结果。比较是公正的吗？从最初开始，许多Java开发者坚持认为原始的比较是无效的，因为Sun的版本在开发效率和性能上都没有进行优化。Java开发者指出，Microsoft实现经过了专门的性能优化，并且与Sun的版本使用的是不同的体系结构。例如，Java开发者指出Microsoft在他们的实现中使用SQL服务器贮存程序（Sun的Java版本使用的是动态SQL，这样使得数据库移动更加方便），这是这两种不同实现的关键区别，这一区别使得.NET版本比Java同类产品运行更加快速。对于这一点，Microsoft坚持认为Sun的应用程序是被作为一个J2EE企业设计最佳实践模板推出的，因此，完全有理由认为应用程序在可伸缩性已经作过了相当好的调整。Microsoft指出它也采用类似的方法将所有.NETPetShop源代码作为.NET企业设计模板的最好实践发布；它使用贮存程序的原因基于这样的一个事实，那就是许多的企业DBA为了控制的方便更趋向于将查询封装在贮存程序，同时许多人甚至不接受在应用程序中的动态SQL。然而，网上的Java开发者例如TheServerS却提出了合法性的问题，例如：●难道J2EE版本不能够重新编写，对其进行优化以实现更好的性能？如果.NET版本不使用贮存程序，而是使用与J2EE版本里相同的动态SQL，那么其性能会发生什么变化呢？对比是否可信？尽管原始的比较使用的硬件是类似的，但并不是相同的，并且比较是由Oracle和Microsoft各自的实验室完成的，使用的是不同版本的MercuryLoadRunner负载测试软件和不同的测试台。修订过的JavaPetStore精通基于Web的J2EE应用程序服务器的Middleware公司，根据Java社区的反馈信息以及企业开发者公布在TheServerSide上的反馈信息，使用J2EE和EJB从新创建了JavaPetStore，对其性能进行了充分的优化，确保新的实现仅仅包含执行应用程序所需要的代码，而没有那些只是用来表明J2EE特征的代码。同时Middleware公司将PetStore应用程序的功能扩展到支持重要的新的企业功能，这些功能包括分布式、适应XA事务以及基于XML的Web服务。这一新的应用程序已经被作为Middleware的JavaPetStore2.0公布在TheServerSide上。同时Microsoft也将他们的.NETPetShop升级到2.0版，增添了支持分布式事务与Web服务的功能，在.NET应用程序中使用所有的动态SQL来代替贮存程序。Microsoft已经将这个新的.NETPetShop2.0版本发布在MSDN上，供.NET开发者在创建他们自己的n层Web应用程序的时候作为一个蓝图使用，同时Microsoft也在ServerSide上公布了源代码。Middleware公司在新的实现中完成了一系列广泛的基准，使用的是与应用程序服务器和数据库后端系统相同的硬件，并且采用了相同的测试台。本文包括了这些有Middleware公司执行并且验证的测试的结果。这些测试包括广泛的J2EE应用程序服务器协调与优化，都是在2002年6月到9月的四个月的时间内进行的。Middleware公司颁布的基准的基本规则包括：J2EE与.NET实现在功能上必须100%的相同，在行为上没有任何的区别。两个实现都必须是根据最佳实践代码准则创建的，这样现实中的消费者在创建他们自己的应用的时候可以遵循每一项有效设计模式服务。每一个应用程序在逻辑上都必须是三层实现，使用分割好的组件来封装中间层商业和数据访问逻辑。应用程序必须设计得使它们都能够跨多中间层应用程序服务器群集来缩小。基准必须与能够响应现实世界产品配置的现实的应用程序服务器和数据库配置设置一起运行。所有的基准应用程序源代码、数据负载以及测试脚本（包括.NET和J2EE）都必须公布在S上，这样客户可以复制并验证其结果。在基准中使用的源代码、数据库结构以及测试脚本可以从下面的网得到：/j2eedotnetbench/。利用新的企业功能扩充PetStore.为了使新的基准更加易于充分理解，J2EE和.NET中的PetStore2.0应用程序需要扩展重要的新的企业功能，其中包括：分布式事务。在原始的Sun的JavaPetStore中，所有的数据库事务都发生在单个的数据库中，而在PetStore2.0基准中，对于每一条命令，都有一项分布式的事务在两个不同的物理数据库之间执行，命令信息放在一个数据库中，而存货统计在另外一个数据库中进行。如果事务中有任何一部分失败，那么整个事务就会再从头开始。创建这样的应用程序与基准的目的是对使用JTA事务服务的J2EEEJB与通过利用COM+事务的.NET服务处理的.NET事务的性能进行对比。Web服务。PetStore2.0包含有一项以XML格式提供命令信息的Web服务，这些信息包括所有命令的详细内容和每一条特殊命令的排列项。Web服务在SOAP1.1上工作。除了Web服务本身外，PetStore2.0还包含一个用来调用Web服务在浏览器中显示结果的简单的客户程序包。改进的JavaPetStore应用程序JavaPetStore应用程序通过许多途径来改进增加其性能。修订后的应用程序仍然保持具有EJB基础的设计模式，类似由J2EE升级而成的可缩放n层企业应用程序。然而，许多性能上的改进对应用程序进行了彻底的性能优化，下面将详细的介绍这些性能的优化。事务边界的改进：尽管大部分原始的PetStore应用程序遵循应用程序的标准访问模式，调用一个EJB会话，这样完成一个事务就需要调用所有需要的EJB实体。改进后这种方法并没有在所有的情况下延续，因为它会导致原始的实施中某些性能的退步。例如，在某一类别所包含的产品报表中，三种各包含有三列的产品需要九次事务才能完成，而不是一次。在改进后的MiddleJavaPetStore2.0中，所有的事务边界都被修改以最小化事务次数为EJB实体实现了一种Read-Mostly模式：在原始的PetStore中，所有的实体都是读写式。这种模式开发简单，但是效率低下，因为每一次操作都会导致读写数据库一次，即便是对静态数据的操作也是如此。为了减轻这个问题的影响，有些适当的实体块被以一种Read-Mostly的模式重新实现。在这种模式中，EJB实体被分成两个部分：一部分为只读模式，其状态保存在事务边界中，另一部分为写模式；两部分实体都分享一个引用，这个引用指向代表它们的数据的通用数据结构。只读实体块界面包含有访问方法，而写实体块界面包含有改变方法；所有的数据库读的方法都包含在只读模式EJB中，例如ejbLoad()，所有的写数据库方法都包含在写模式EJB中，例如ejbStore()。此外，在整个实体中添加了isModified()方法，该方法可以写入数据库这样所有不必要的数据库更新都可以避免。改进了数据库索引的使用：改进后在一般的搜索方面都可以使用索引，例如搜索产品的名字以及样品ID。此外，原始PetStore的表格生成脚本中的一个主要关键字被忽略了，而这个关键字往往使得详细目录的访问非常的慢。去掉多余的JNDI查找和调用初始化：每一个数据资源与EJB原参考都储存在应用程序服务器的JNDI服务中。在原始的PetStore中，每次在这些参考被使用的时候，系统都要找出JNDI初始背景，然后在JNDI中查找相应的参考。两者都仅仅只需要做一次就可以了。代码的改变使得所有不必要的JNDI调用都省去了。动态类只有一次初始化：在PetStore中使用的一种在编译的时候载入不知名的类的设计模式就是用来显示Java的灵活性的。它通过查找将要作为字符串使用的类的名字，使用forName()操作来为该类生成实例来完成。然而，进程的灵活性的代价就是执行上的高耗费。那些类的名字在编译时已经知道的情况下，程序将这一过程移除同时类的名字被编码。在其余的情况下，程序确保类的查找和确定只执行一次，然后只有在此类生成新的实例的时候再次执行。就像前面提到的一样，还有许多其他的改进：包括广泛的使用JDBC预定义的语句，对字符串处理的重大改变以及其它的重大改进。然而，上面详细列出的这些改变带了了性能上的最大的改观。基于J2EE应用程序服务器A比较性的性能数据，与Sun公司最初实施的JavaPetStore相比，这些优化大致对性能提高了17倍。这一数据是根据对进行性能平衡（对分布式事务的支持，数据的高速缓存）后原始SunJavaPetStore与新的MiddlewareJ2EEPetStore2.0的比较得出的。新的实施与旧的实施相比，性能上的提高见下表：图1.原始的SunJavaPetStore与优化后的EJBJavaPetStore2.0峰值吞吐量的比较改进后的.NETPetStore2.0和JavaPetStore类似，.NETPetShop2.0的体系结构是由Microsoft推出的3层逻辑结构，其目的是为了创建基于.NET的可缩放的企业应用程序。然而，在某些关键的地方，代码基础已经作了最新的改进，同时做了性能上的提高。最主要的改变包括：对于所有的数据库访问，使用动态SQL代替贮存程序。这样就消除了关于性能的提高是通过加入编译过的贮存程序，牺牲了数据库的轻便实现的争论。在命令布置中使用了分布式事务。使用一种基于SOAP的Web服务来返回命令的详细信息以及调用客户页面。使用数据转发器控制代替数据栅格控制来提高性能。使用简单的数据高速缓冲存储器在中间层数据缓冲存储器中缓冲静态只读产品信息。新的.NETPetShop2.0以及其完全体系结构白皮书可以从下面的网址下载：/library/default.asp?url=/library/enus/dnbda/html/bdasamppet.asp.新的实现的比较改进后的JavaPetStore实现仍然保持忠实于Sun微系统发布的Model-View-Controller体系结构，充分利用包括会话块与实体块的J2EE核心特征的优势。在对软件进行上面详细列出的为优化性能而做出的广泛修改的同时，软件方面由Sun微系统推荐的基本设计模式以及广泛应用的面向对象的开发方式仍然保持完整无缺。这一体系结构使得用户界面与中间层商业逻辑以及数据访问逻辑完全分离，后端进程被封装在不同的EJB中。类似的，.NETPetShop2.0也采用了完全面向对象的n层体系结构，为中间层和数据访问目标实施了C#类。这样它就实现了通过使用ASP.NETWeb表单将UI与中间层商业逻辑完全的分开，而ASP.NETWeb表单则通过使用一种code-behind模式（服务器端的代码通过封装与客户端HTML分开）将HTML和客户端单元与服务器端进程单元完全分开。Web表单模式利用了框架中提供的ASP.NET服务器控制的优势，为大部分的UI/外观单元服务，例如列表，网格等。反过来，服务器控制激活用C#语言书写的封装在单独的.NET集合（封装的、可重复使用的组件）中的中间层对象，这些中间层间接的通过封装在数据访问逻辑中的单独的一套数据库访问类在访问数据库。状态/高速缓冲存储数据的一个比较为了使得呈现在用户面前的数据库信息尽量是最新的，必须确保两种实现有相同的行为。基本上来说，核心静态产品数据一般每24小时从数据库更新一次（尽管搜索仍然会查询数据库关键字来确定高速缓冲存储器中的哪些记录需要显示，但是主要是在运行测试的时候在中间层高速缓冲存储器查找），而消费者数据和用户目录却需要在每一位用户登录的时候都访问数据库，同时从数据库中更新帐单信息，这也是结帐过程的一部分。此外，所有产品详细目录的数量必须精确响应所有显示这些信息的应用程序页面更新后的数据库信息。Java版使用实体块来维持状态数据库信息；而.NET版使用.NET中间层高速缓冲存储器来储存静态（只读）产品信息，高速缓冲存储器每24小时更新一次。考虑到数据的过时，这种配置在产品间具有相同的欣慰。在这一基准中，尽管.NET和J2EE应用程序服务器都被测试出支持页面输出高速缓存，但是动态页面输出缓存并没有使用。这样的决策的目的是强调中间层应用程序逻辑处理的性能。扩展的基准这一基准包含有三套单独的测试，这些测试可以为两个应用程序.NET和J2EE性能与缩放性特征提供一个公平全面的概括。这三套基准包括：Web应用程序基准24小时基准分布式事务基准Web服务基准Web应用程序基准这一基准联系应用程序大部分的基本功能，在使用Oracle和Microsoft的测试中，两个应用程序的工作量相似，但并不相同。测试的目的是得到应用程序在低用户负载量到高用户负载量的过程中吞吐量曲线以及测量响应时间，不给两种产品施压以测定他们分别在2个、4个和8个CUP应用程序服务器的配置下能够支持的用户数量的极限。测试脚本在有10秒缓冲时间的情况下执行（在Oracle的原始基准中，使用了20秒的缓冲时间，这就意味着与新的基准相比，在相同用户负载量的情况下，服务器所承受的压力只有一半）。页面输出高速缓冲存储也被停止，这样保证服务器必须处理收到的每一条请求。不同用户负载量下的数据点都被单独的测量，同时测量ramp-up、settledown、数据收集和rampdown时间来测定结果的精确性（每一个单独数据点的总执行时间都超过1小时）。为了得到更多的信息，这套基准以两种不同的方式执行：关闭图片下载：这样只有基本应用程序服务器引擎被使用到。这一测试可以显示产品操作包括服务器端脚本、会话状态管理、对象激活以及数据库连通性在内的应用程序逻辑的良好程度。打开图片下载：模拟一个浏览器高速缓冲存储器这样，每个访问站点的用户在一次脚本重复期内都需要下载每一张单独的图片一次。这一测试可以显示应用程序服务器作为Web服务器/应用程序服务器的综合工作的合适程度。注意，这一基准的结果不能与过去OracleandMicrosoft公布的PetShop的基准数据比较，因为使用了不同的测试脚本和缓冲时间，同时在应用程序的某些功能方面也与原始的PetShop基准有差别。24小时分布式事务基准设计这一基准的目的是为了对每一个测试产品的分布式事务执行能力进行测试。测试脚本包括用户登录、然后单独的处理一条100条项目的命令。命令中每一条项目结帐过程的完成包括这个过程的最后一步就是用来激活一次分布式事务的命令的实际布置，脚本的最后是退出。每一个用户在一个用户会话中都会完成100次单独的分布式事务。测试会在每一个产品能够产生峰值吞吐量的用户负载下运行，并且持续24小时来观察这种吞吐量是否可持续。价格性能度量除了绝对性能度量外，每个产品基于4-CPU配置在24小时的运行中的价格度量也被计算出来了。这一度量是以每次事务每秒花费的美元数来计算的。花费包括中间层的硬件的开销、应用程序服务器软件许可证开销（以4-CPU配置的每个产品的发布价格来计算）再加上用于应用程序服务器的操作系统的购买价格。价格度量中没有包括数据库许可证费以及接下来的支持维护费用。Web服务基准这一基准测量为J2EE和.NET服务的Web服务的性能特征。测试包括两个基本的配置：Web服务的直接激活使用100台分布式的物理计算机，每一台模拟多用户生成直接SOAP调用来激活Web服务。这一基准测试应用程序服务器处理SOAP请求的能力以及作为Web服务提供者的能力。Web服务的远程激活应用程序服务器通过一个代理对象。在这种配置下，一共配置两台物理的应用程序服务器，一台作为一个远程Web服务提供者（就像测试a中的那样）做工，另外一台作为Web服务客户端而工作。100台物理客户端计算机向应用程序服务器计算机发送HTTP/HTML请求形成负载，应用程序服务器计算机接着向Web服务提供者计算机发送SOAP请求。设计这一测试的目的是测试应用程序服务器Web服务客户端性能以及发送基于对象激活的远程SOAP的性能。测试实验室与测试软件由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利用在测试过程中都被监控以保证这些设备不会成为瓶颈。在所有的J2EE和.NET的实例中，测试会精确的报告用于应用程序测试的应用程序服务器软件本身的能力。图2.基础Web应用程序基准、24小时分布式事务基准以及Web服务直接SOAP激活基准测试的实验室布置。图3.带有在应用程序服务器之间远程SOAP调用的远程/代理Web服务基准测试的实验室布置产品测试Microsoft.NET对于.NET产品，Middleware公司测量的是其商业发布的运行在Windows2000下的.NETFramework1.0(SP2)以及在Windows.NETSever2003的RCBuild3681上创建4322.508的.NETFramework1.1RC。在测试中作为后端使用的是MicrosoftSQL服务器2000数据库。.NET1.0and.NET1.1在配置上的精确优化在附录7.8中给出。测试前.NET协调以及优化配置需要的时间.在开发出.NETPetShop2.0后（这个应用程序实际上是由一家设立在California的Microsoft解决方案提供者开发成功的），一个Microsoft员工花了大约2个星期的时间试运行，在Middleware公司测试前（单人2周的工作量）对程序进行包括配置设置方面的优化。.NET协调与优化配置.优化就是在.NETFramework设置的基础上作些微小的变化。优化包括：1．确保数据库正确的协调，拥有足够的存储空间来为小时事务的沉重运载量分配存储空间。2．对基础ASP.NET设置作了修改，使得表单认证可以与基于Windows的认证对比，因为应用程序本身是一个能够通过任何拥有标准窗口的客户端平台访问的稀少客户应用程序（认证是以一个记录有用户名和密码的数据库为基础的）。3．将ASP.NET工作器和IO线程从25个（Windows2000的缺省设置）下调到20个；微小的上调在Web服务运行期间每一个客户端IP被允许的Web连接的数量来保证服务器允许每个负载生成客户端可以激活足够多的向.NET应用程序服务器的同步Web连接。4．在Windows2000的测试中，设置ASP.NET进程模式以便.NET应用程序可以运行在与IISWeb服务器一样的进程空间。5．在Windows.NETServer2003的测试中，使用了新的IIS6.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应用程序服务器的测试采用Oracle9i后端数据库，因为这种数据库是每种产品首推使用的数据库，拥有完整的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（单人10周的工作量）协调以及优化配置。对两台J2EE应用程序服务器的调整和优化配置过程是非常重要的，下面将会详细的讲解。J2EE协调与优化配置J2EE应用程序由Middleware专家根据最有经验的销售者的指导对测试的不同的应用程序服务器产品分别作了广泛的协调。协调包括用不同的JavaRuntimeEnvironment(JRE)以及数据库驱动程序检测产品以得到最优组合；以及基本应用程序服务器设置优化，例如堆阵规模、高速缓冲存储块以及线程设置。在对两个应用程序服务器的协调过程中，首先考虑到的是将要使用的JavaRuntimeEnvironment(JRE)和JDBC驱动器的选择。这里，一共测试了四种JRE：SunSoft1.3和1.4、JRockit3.1以及IBM1.3。对于应用程序服务器A来说，SunSoft1.4是最快的，在基准中可以比SunSoft1.3产生多出50%的吞吐量。然而，因为SunSoft1.4的兼容性问题，它能够用于Web应用程序和分布式事务基准，却不能够用于J2EE应用程序服务器A来做Web服务测试，所以在这里选择了JRockitJRE。这些JRE性能的一个重要的因素就是并发的碎片收集实现。如果这个特征不能够实现，那么由于碎片收集导致的暂停就会变的多余并且会导致在高负载量时发生“拒绝连接”的错误，因为应用程序服务器进程在碎片收集的过程中会停止工作。因为比SunSoftJVM1.3相比提供更加优化的碎片收集的SunSoftJVM1.4与产品一起工作（在Web服务测试中例外），J2EE应用程序服务器A会从中受益。然而J2EE应用程序服务器B不与SunSoftJVM1.4兼容，因此，只能够使用SunSoftJVM1.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驱动器的选择需要基于以下标准：特性的实用性：对事务的支持以及可滚动的结果设置整体性能一共测试了四种驱动器：数据库提供者的驱动器（Oracle）、应用程序服务器提供者的驱动器以及两个领先的第三方驱动器提供者。在排除掉那些没有必备特征的驱动器后，剩下的驱动器在负载下作了性能与稳定性测试。在决定采用JRE和JDBC驱动器后，应用程序服务器同时作了应用程序服务器参数和Java运行时间参数协调。除了协调额外的服务器实例外，通过在应用程序服务器引擎上运行多个服务器进程使得性能得到了很大的提高，应用程序服务器引擎使用DNS在服务器实例间平衡负载。这种配置对两个应用程序服务器的大部分都是最理想的，因为它允许使用服务器上所有的内存，然而，每一个兼容产品必须单独使用更少的内存用于碎片收集，这就意味着周期性的碎片收集将会更加快速，减少进程相应的暂停时间。Web应用程序基准测试该平台包含两个脚本，比重各占一半，一个脚本用以模拟用户简单的浏览网址，另一个则模拟从网站寻找以及购物。在只有浏览功能的脚本中，用户需要如下操作：登录网站主页；对1000种产品进行三次任意的文字查询，在每次查询结果的网页上，单击“下一步”按钮；在某种范围内检验产品，重复三次；对某种产品具体内容检验三次（包括产品存货纪录的实时读取）；对于具有浏览和查询功能的脚本，模拟用户需要：对1000种产品进行两次任意的文字查询，在每次查询结果的网页上，单击“下一步”按钮；利用100，000个用户中的任意ID，在网站注册；在购物车中添加50000个中的两个项目；检验，确认账户信息，然后根据购物车中的项目下订单；有一半时间用户用于退出操作，而一半时间不是这样，于是，50%的活动被关闭，同时放弃这50%时间使得应用程序服务器可以处理关闭操作，关闭时间设定为10分钟，即如果10分钟内没有任何操作，则关闭之。这种做法是真正的电子商务网站对现实活动的合理模拟。购物完成后，执行最后一次文字检索。测试方法对每种产品进行测试都包含两个完全独立的方法，一种是关闭图像下载功能，另一种是开通图像下载功能（客户端具有浏览器缓存）。这么做是为了更全面的了解应用程序服务器性能，该性能包括两个方面，一个是终端处理情景，应用程序服务器本身不为PetStore站点图像提供服务；另一个是一般情况处理情景，应用程序服务器处理程序逻辑，同时提供下载图片到浏览器的功能。注意，.NETPetShop和MiddlewareJ2EEPetStore在其运行过程中采用不同的图像。于是，就图像而言，.NETPetShop必须加以修正，才能打开J2EEPetStore图片，这样每种测试产品的图像数量以及图像尺寸就相同了。另外，利用模拟浏览器缓存下载图片时，程序设置已经被固定，因此在用户不断使用过程中，对每个用户而言，同一图片只能被下载一次，这类似于浏览器缓存确保图片因速度原因而在客户端存储的实际设置。于是，网页中的普通图片，例如导航条，每个用户只能下载一次，即便他作为一个模拟用户在脚本执行过程中访问多张网页。但是每个模拟用户的浏览器缓存都是事先固定的，因而他们必须各自重定义自己的图像缓存。这些测试是在2个，4个以及8个CPU配置上运行的，目的在于了解当系统增加CPU时应用程序服务器功能的垂直变化。对于每个数据点，其数据运行由数据激增，平稳，数据收集以及数据量减小这几个部分组成。从每个数据运行一小时的综合结果来看，只有当系统达到稳定状态时才开始数据收集。对单个产品而言，直到用户登录的响应时间达到3秒或者更大的时候，数据点才被获取，因为每个产品如果在这些用户登录数以上进行测试通常出错。所以那些功能扩展到承受更大用户量的产品才可以收集更多数据点。Web应用程序结果（关闭图片下载功能）图4：吞吐量峰值图5：网页平均响应时间为3秒时的最大支持用户数图6：双CPU应用程序服务器的吞吐量曲线图7：4CPU应用程序服务器的吞吐量曲线图8：8CPU应用程序服务器的吞吐量曲线Web应用程序结果（启动图片下载功能）图9：吞吐量峰值图10：网页平均响应时间为3秒时的最大支持用户数图11：2CPU应用程序服务器的吞吐量曲线图12：4CPU应用程序服务器的吞吐量曲线图13：8CPU应用程序服务器的吞吐量曲线24小时分布式基准设计分布式处理平台的脚本是为了全面测试服务器处理大量分布式处理登录的能力，本文的测试对象则是编写命令。该脚本利用模拟用户进行如下操作：从10万个有效用户名中任选一个，填写资料登录网站；从5万个项目任选一个加入购物车，并且立即订购，每登录一次则如此操作100次。于是对于每次登录，检验程序就需要运行100次，包括验证账户信息以及根据购物车（一个分布式处理系统）的内容处理订单；退出。需要注意的是本测试中实际分布式处理事务与总的系统请求比率为1：5，因为服务器的检验程序是一个5步骤、5页面的订单确认/订单处理程序。该分布式处理平台运行在4CPU程序服务器上，用户登录数量达到最大值，所测试的每个程序服务器产品，其持续吞吐量如下表所述：图14：分布式处理平台测试结果程序服务器最大用户登录吞吐量每秒钟分布式处理事务所下订单价格/性能1J2EEApplicationServerA4,00059TPS$1,305J2EEApplicationServerB1,00018TPS2(不能支持，见脚注)$4,722(见注释2).NET1.0/WINDOWS20004,00079TPS$468.NET1.1/Windows.NETServer20036000117TPS$31631参见附录2，应用程序服务器系统硬件/软件总表2J2EE应用程序服务器B不能在分布式处理平台连续2个小时支持最大用户负荷。它也不能连续4个小时支持任何吞吐量，超出这个时间将会出现错误。3估计值，根据Windows2000AdvancedServer价格。Windows.NETServer2003价格未公布。图15：用MercuryLoadRunner分析J2EE应用程序服务器A运行结果，显示24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第二部分处理事务的验证量。注意：前6个小时吞吐量略有下降，而后TPS则稳定在24小时的平均处理水平59个命令/每秒。图16：用MercuryLoadRunner分析J2EE应用程序服务器B运行结果，显示了24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第二部分处理事务的验证量。注意：分布式处理平台的峰值吞吐量不能持续2小时以上。对参数做各种调整进行四十多次测试表明，J2EE应用程序服务器B处理数据库的分布式XA兼容处理有明显难度。以上测试具有代表性的，TPS略有下降，继而是急剧下降，上升，而后是程序服务器失败，以至于4小时以上不能成功处理请求。图17：用MercuryLoadRunner分析Microsoft.NET1.0/Windows2000Server运行结果，显示了24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第二部分处理事务的验证量。注意：吞吐量24小时持续稳定，24小时平均命令处理的TPS是79个/秒。图18：用MercuryLoadRunner分析Microsoft.NET1.1/Windows.NETServer2003运行结果，显示了24小时的吞吐量。该图描述连续24小时Web请求每秒钟事务处理量。注意，实际订单操作（分布式处理）是第二部分处理事务的验证量。注意：吞吐量24小时持续稳定，24小时平均命令处理的TPS是117个/秒。Web服务基准因为Web服务作为应用程序服务器的一项新领域已经被广泛的推出，所以新的PetStore基准的扩展功能就是用来检验一个原型Web服务的每一个应用程序服务器的性能。因为Web服务自身的规定，所以它能够提供现实的测试实例来证明应用程序服务器的性能，以通过SOAP激活基本目标和将简单和复杂数据类型/对象串行化为XML文件的性能。PetStore中的Web服务的功能就是将单个输入参数作为一个定单ID，然后执行在数据库中寻找这个定单的动作，最后将定单对象作为XML文件返回给调用程序。定单对象本身既包含简单数据类型（字符串、整数型、小数型）也包含数组（代表某个条目详细的排列项）。图19.从基于SOAP1.1的Web服务调用返回定单对象的基本XML模式<GetOrderResult><orderId>int</orderId><date>dateTime</date><userId>string</userId><cardType>string</cardType><cardNumber>string</cardNumber><cardExpiration>string</cardExpiration><billingAddress><firstName>string</firstName><lastName>string</lastName><address1>string</address1><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><address1>string</address1><address2>string</address2><city>string</city><state>string</state><zip>string</zip><country>string</country><phone>string</phone></shippingAddress><lineItems><item><id>string</id><line>int</line><quantity>int</quantity><price>decimal</price></item><item><id>string</id><line>int</line><quantity>int</quantity><price>decimal</price></item></lineItems></GetOrderResult>有两种Web服务测试方案。第一种方案就是测试客户端直接通过一条以HTTP方式发送（在这种情况下，MercuryLoadRunner软件通过HTTP直接发送SOAP1.1请求）的SOAP消息调用Web服务。另外一种方案是LoadRunner客户端在运行在应用程序服务器计算机1上的ASPX或JSP上生成一条HTML/HTTP请求，然后这台计算机通过SOAP1.1的HTTP调用一个运行在另外一台应用程序服务器计算机2上的远程Web服务。在第一种方案中，客户端将会发送一条SOAP请求，要求在返回的定单对象中包含10000条可能的定单中随意的一条，而每条定单都包含有5个重复的行条目。这一测试对提供Web服务的单个应用程序服务器产生了很大的压力，这样设计的目的是为了验证应用程序服务器作为一个Web服务主机工作的性能以及从成千上万的并发用户总提供SOAP请求服务的能力。在第二种方案中，LoadRunner客户端使用ASPX或JSP页上的一条HTTPURL，该页带有一个介于1到10000的请求定单号码中随意一条查询字符串定单号码。然后ASPX或JSP页向另一台提供Web服务的应用程序服务器发送远程Web服务SOAP请求，得到一个返回的有效的定单对象，然后将定单对象的一部分（定单的用户ID）格式化为JSP/ASPX页作为HTML文件返回给客户端。这个测试模拟一个企业应用程序整合方案，该方案中Web服务用来将多（也可能是不同的）后端系统联系在一起，说明应用程序服务器作为一个Web服务客户端的合适程度。在这个方案中，Web服务主机为8CPU配置，而生成远程Web服务请求以及将结果格式化为HTML的客户端计算机则有2个、4个、8个CUP配置。每一种方案的测试结果图如下所示。Web服务基准——直接Web服务请求图20.峰值吞吐量图21.最大用户负载·平均页面响应阈值3秒图22.2CPU应用程序服务器的吞吐量曲线图23.4CPU应用程序服务器的吞吐量曲线图24.8CPU应用程序服务器的吞吐量曲线WEB服务基准——远程SOAP客户端请求图25.峰值吞吐量观察结果:在J2EE应用程序服务器A和B上，8CPUWeb服务主机在大约200TPS下达到CPU饱和状态，因此，8CPU与4CPUWeb服务器客户端配置相比，吞吐量几乎没有任何的改善。在Microsoft.NET（包括Windows2000和Windows.NET服务器）上，Web服务主机在Web服务客户端计算机达到饱和之前并没有达到饱和，因此8CPU与4CPUWeb服务器客户端配置相比，可以提高吞吐量。图26.最大用户负载·平均页面响应阈值3秒图27.2CPU应用程序服务器的吞吐量曲线图28.4CPU应用程序服务器的吞吐量曲线图29.8CPU应用程序服务器的吞吐量曲线附录1——代码行对比Middleware公司的JavaPetStore2.0实现使用的了与原始的JavaPetStore（除了对性能进行充分的优化外）相同的基础EJB推荐的体系结构。因此，其代码行的数量与原来的14004行的代码相比，并没有很大的改变。而对于.NETPetShop2.0实现，Microsoft则做了更进一步的优化以减少总代码行数，同时也扩展了一些为分布式事务和Web服务服务的新特征。新的.NETPetShop2.0一共有2096行C#代码（在1.5版本中一共有3484行代码，新的版本减少了40%）。.NET和J2EE的版本都是完全的面向对象的，都是对UI层、中间层和数据层应用程序逻辑进行分离的n层逻辑结构。完全代码细目分类如下：图30.不同实现中不同代码行的列表描述图31.代码行对比附录2——Web应用程序基准的基准数据关闭图片下载吞吐量数据吞吐量数据通过应用程序服务器在不同用户负载量下平均每秒的http响应次数（命中数）来计算的。注意这里图片下载被关闭，所以测量的是服务器每秒种能够处理的真实的用户请求的数目。2CPU应用程序服务器(pgs/sec)4CPU应用程序服务器(pgs/sec)8CPU应用程序服务器(pgs/sec)事务响应时间（秒）注意事务响应时间是两种方案中所有包括浏览与定单在内的单一页面响应时间一个以秒数计算的加权平均值。它表明一个用户需在应用程序处于不同用户负载量的情况下完成一次Web请求平均需要等待的时间。2CPU应用程序服务器（秒）4CPU应用程序服务器（秒）8CPU应用程序服务器（秒）打开图片下载吞吐量数据通过应用程序服务器在不同用户负载量下平均每秒的http响应次数（电击数）来计算，其中包括在图片还没有倒入浏览器缓存的时候每个页面上返回的图片。因为在这个度量中包含了图片，所以与关闭图片下载相比，在相同的用户负载量下，这种情况得到每秒的命中次数更高，然而，服务器在更高的事务响应时间下更快的达到饱和状态。吞吐量数据（每秒的图片与页面的数量）2CPU应用程序服务器（每秒的页面数和图片数）4CPU应用程序服务器（每秒的页面数和图片数）8CPU应用程序服务器（每秒的页面数和图片数）事务响应时间（秒）在打开图片下载的时候，这个测量值包括从服务器上返回包括下载的图片在内的每页需要的时间。2CPU应用程序服务器（秒）4CPU应用程序服务器（秒）8CPU应用程序服务器（秒）附录3——24小时分布式事务基准的基准数据对于这一基准来说，峰值吞吐量是由4CPU应用程序服务器决定的。然后测试在这一用户负载量下运行24小时。测试的目的是检测在整个时间段内峰值吞吐量是否稳定。按照TPS和$/TPS的事务性能比较*价格性能的计算是将应用程序服务器中间层许可证的所有开销相加，其中包括操作系统（Windows2000高级服务器和Internet连接器）的费用、硬件的花费、4CPU配置的应用程序服务器软件费用，分门别类列在下表中。数据库软件和维护/支持费用没有包括在内。预计的应用程序服务器软件与硬件系统的费用4包括基于4CPU配置的每个CPU许可费，4CPU配置可以提供企业功能，包括群集多管理服务器的功能。5操作系统的花费包括拥有25个客户访问许可（$3,995）的Windows2000高级服务器的许可证费用以及一个用来匿名访问服务器的Internet连接器许可证费用（$1,995）6一台带有4个CPU和2个GIGRAM的CompaqProLiantDL760的基本花费（Compaq8500的替代模型）7以Windows2000高级服务器的价格为基础评估得到。Windows.NET服务器2003的价格还没有公布。附录4——Web服务基准的基准数据来自于负载源的Web服务直接SOAP激活吞吐量（每秒的响应次数）2CPU应用程序服务器（次数/秒）4CPU应用程序服务器（次数/秒）8CPU应用程序服务器（次数/秒）响应时间（秒）2CPU应用程序服务器（秒）4CPU应用程序服务器（秒）8CPU应用程序服务器（秒）Web服务远程SOAP客户端调用吞吐量（每秒的响应次数）每秒钟的响应次数是按照每秒钟由Web服务客户端应用程序服务器返回的有效页面数来计算的。为了返回一个页面，客户端应用程序服务器必须通过自己的代理对象激活远程Web服务，然后等待一个SOAP响应，接着在将页面返回调用用户之前将响应格式化为HTML文件。2CPU应用程序服务器（次数/秒）4CPU应用程序服务器（次数/秒）8CPU应用程序服务器（次数/秒）响应时间（秒）2CPU应用程序服务器（秒）4CPU应用程序服务器（秒）8CPU应用程序服务器（秒）附录5——J2EE应用程序服务器A的协调Web基准JRE—SunSoft1.4，可以选择—服务器—Xms350m—Xmx350m-XX：编译阈值=3500和—Xconcgc非XA的JDBC—Oracle9.2thick驱动器XA的JDBC—应用程序服务器卖方thickOracle驱动器应用程序服务器的线程数目为2处理器的7个，4处理器的5个，8处理器的4个。对于每一级别的处理器来说，运行的服务器实例数等于处理器的数目。每一个服务器实例在一个配置好的单独的模式下运行。分布式事务基准与上面的Web基准相同Web服务基准JSP（Web服务客户）服务器：JRE—SunSoft1.4，可选择—Xms200m—Xmx200m以及—Xconcgc服务器线程数10个Web服务服务器JRE—JRockit3.1.5，可选择—客户—Xms400m—Xmx400m，注意，SunSoft1.4与应用程序服务器服务的Web服务API不兼容服务器线程数4个JDBC—Oracle9.2thickdrivers对每一个级别的处理器，正在运行JSP服务器的数目与运行Web服务的服务器的数目相等。这些数目分别是：2处理器的为2个，而4处理器和8处理器的都是4个。每一个服务器实例按照上面的配置运行在独立的模式下，通过客户端DNS监视单独的可寻址的IP地址。附录6——J2EE应用程序服务器B的协调Web基准JRE—IBM1.3，可以选择—服务器—Xms512m—Xmx512m非XA的JDBC—Oracle9.2thin驱动器XA的JDBC—Oracle9.2thin驱动器对所有级别的处理器应用程序服务器线程的数目都是22个对所有级别的处理器，Web服务器线程的数目最大值都是50，正在运行的应用程序服务器实例的数目是2。Web服务器使用ship作为应用程序服务器测试的一部分，因此它也是产品软件包的一部分。分布式事务基准与上面的Web基准相同。Web服务基准JSP（Web服务客户端）服务器：JRE—IBM1.3，可选择—服务器—Xms512m—Xmx512m服务器线程数目为22个Web服务服务器JRE—IBM1.3，可选择—服务器—Xms512m—Xmx512m服务器线程数目为22个JDBC—Oracle9.2thin驱动器对每个级别的处理器，运行的JSP服务器的数目为2。附录7.NET1.0/WINDOWS2000服务器协调配置作了如下的改变：基本全局变量的修改：设置IIS5.0验证，关闭Windows复合验证，允许匿名用户访问PetShop虚拟目录（匿名用户通过.NET基于表格的验证在登录处验证）。将IIS性能标签设置成允许每天大于100000次命中。指向应用程序服务器和产品数据库服务器上的COM+本地分布式事务协调程序（DTC），这样可以在定单数据库中使用DTC来协调分步市事务日志工作。确保在ASPX页面的顶端作如下设置：“autoeventwireup=ture”。Web基准Machine.config文件的变化：<httpRuntime..appRequestQueueLimit="4000"/>//这个简单的调整的作用是设定服务器在返回“服务器正忙”的错误前允许的最大排队等候请求数量。应该根据系统进程的数目以及服务是希望用户在返回页面前等待一段时间或者得到一个系统正忙的错误信息来调整。<authenticationmode="表单s"><processModelenable="False"..maxWorkerThreads="20"maxIoThreads="20"/>分布式事务基准Machine.config文件的变化：<authenticationmode="表单s"><httpRuntime..appRequestQueueLimit="4000"/><processModelenable="False"..maxWorkerThreads="12"maxIOThreads="12"/>Web服务基准Machine.config文件<connectionManagement><addaddress="*"maxconnection="32"/></connectionManagement><httpRuntime..appRequestQueueLimit="4000"/>minFreeThreads="32"minLocalRequestFreeThreads="16"/><authenticationmode="表单s"><processModelenable="False"..maxWorkerThreads="16"maxIOThreads="16"/>附录8——.NET1.1/WINDOWS.NET服务器2003协调协调作了如下配置的改变。注意，这些设置适用于已经发布的侯选者Windows.NET服务器2003和.NETFramework1.1，它们有可能和最后发布的产品有所差别。基本全局配置的改变：设置IIS5.0验证，关闭Windows复合验证，允许匿名用户访问PetShop虚拟目录（匿名用户通过.NET基于表格的验证在登录处验证）。指向应用程序服务器和产品数据库服务器上的COM+本地分布式事务协调程序（DTC），这样可以在定单数据库中使用DTC来协调分步市事务日志工作。确保在ASPX页面的顶端作如下设置：“autoeventwireup=ture”。添加注册锁。[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Http\Parameters\MaxConnections]值为40000（默认为调低这个值以防止服务器受到攻击，但是为了保证高的同步用户数量或者基准方案，这个值应该调高）。Web基准创建两个站点（指向同一个应用程序文件），每个监听一个子网/IP。为两个站点分别创建一个应用程序存储池。这样应用程序有两个工作器进程。Machine.config文件的改变：<httpRuntime..appRequestQueueLimit="4000"/><authenticationmode="表单s">分布式事务基准与Web基准相同Web服务基准Web服务主机默认的应用程序存储池中有两个工作器进程。Machine.config文件的变化：<connectionManagement><addaddress="*"maxconnection="32"/></connectionManagement><httpRuntime..appRequestQueueLimit="4000"minFreeThreads="32"minLocalRequestFreeThreads="16"/><authenticationmode="表单s">Web服务客户机创建两个站点（指向同一个应用程序文件），每个监听一个子网/IP。为两个站点分别创建一个应用程序存储池。这样应用程序有两个工作器进程。Machine.config文件的变化：<connectionManagement><addaddress="*"maxconnection="32"/></connectionManagement><httpRuntime..appRequestQueueLimit="4000"minFreeThreads="32"minLocalRequestFreeThreads="16"/><authenticationmode="表单s">附录资料：不需要的可以自行删除HYPERLINK""电脑高手常用技巧应用全接解1、如何实现关机时清空页面文件打开“控制面板”，单击“管理工具→本地安全策略→本地策略→安全选项”，双击其中“关机：清理虚拟内存页面文件”一项，单击弹出菜单中的“已启用”选项，单击“确定”即可。2、如何自行配置WindowsXP的服务如果你是在单机使用WindowsXP，那么很多服务组件是根本不需要的，额外的服务程序影响了系统的速度，完全可将这些多余的服务组件禁用。单击“开始→控制面板→管理工具→服务”，弹出服务列表窗口，有些服务已经启动，有些则没有。我们可查看相应的服务项目描述，对不需要的服务予以关闭。如“Alerter”，如果你未连上局域网且不需要管理警报，则可将其关闭。3、Smartdrv程序有什么作用现象：在许多有关WindowsXP安装的介绍文章中都提到：“如果在DOS下安装WindowsXP非常慢，肯定是安装前未运行Smartdrv.exe。我想问这个Smartdrv.exe文件有什么饔?具体如何使用?Smartdrv.exe这个文件对于熟悉DOS的朋友肯定很清楚，主要作用是为磁盘文件读写增加高速缓存。大家知道内存的读写速度比磁盘高得多，如果将内存作为磁盘读写的高速缓存可以有效提高系统运行效率。Smartdrv.exe这个文件在Windows各个版本的安装光盘中或是硬盘上的Windows/command/里都有，只有几十KB，把这个文件复制到软盘下，启动系统后直接运行这个程序(可以不加参数，该程序会自动根据内存大小分配适当的内存空间作为高速缓存)，再安装WindowsXP即可。另外提醒大家，这个程序在安装完Windows后，不要运行，否则Windows可用内存将减少。4、Win32k.sys是什么文件现象：我刚装了WindowsXP，可是接下去再装毒霸就发现病毒，位于F:WINNTSYSTEM32里的Win32k.sys文件，删又不可删，隔离又不行，在Windows98下或DOS下删就会导致WindowsXP不可启?，请问该文件是干什么用的，有什么方法解决??这个文件是WindowsXP多用户管理的驱动文件。在X:WindowsSystem32Dllcache目录下有此文件的备份。只要将此备份拷到X:WindowsSystem32下替代带病毒的文件即可。做一张Windows98启动盘，并将Attrib.exe文件拷入软盘，此文件在装有Windows98的机器上的X:WindowsCommand目录下。在BIOS的AdvancedBIOSFeatures中将启动顺序调整为从A盘启动，进入DOS后，进入X:WindowsSystem32目录，输入Attrib-s-h-rwin32k.sys，再进入X:WindowsSystem32dllcache目录下输入同样命令，再用copywin32k.sysX:windowsSystem32覆盖原文件，再重新启动即可。5、WindowsXP的开机菜单有什么含义现象：最近我安装了WindowsXP操作系统，我知道在启动时按F8键或当计算机不能正常启动时，就会进入WindowsXP启动的高级选项菜单，在这里可以选择除正常启动外的8种不同的模式启动WindowsXP。请问这些模式分别代表什么意思?(1)安全模式：选用安全模式启动WindowsXP时，系统只使用一些最基本的文件和驱动程序启动。进入安全模式是诊断故障的一个重要步骤。如果安全模式启动后无法确定问题，或者根本无法启动安全模式，那你就可能需要使用紧急修复磁盘ERD的功能修复系统了。(2)网络安全模式：和安全模式类似，但是增加了对网络连接的支持。在局域网环境中解决WindowsXP的启动故障，此选项很有用。(3)命令提示符的安全模式：也和安全模式类似，只使用基本的文件和驱动程序启动WindowsXP。但登录后屏幕出现命令提示符，而不是Windows桌面。(4)启用启动日志：启动WindowsXP，同时将由系统加载的所有驱动程序和服务记录到文件中。文件名为ntbtlog.txt，位于Windir目录中。该日志对确定系统启动问题的准确原因很有用。(5)启用VGA模式：使用基本VGA驱动程序启动WindowsXP。当安装了使WindowsXP不能正常启动的新显卡驱动程序，或由于刷新频率设置不当造成故障时，这种模式十分有用。当在安全模式下启动WindowsXP时，只使用最基本的显卡驱动程序。(6)最近一次的正确配置：选择“使用‘最后一次正确的配置’启动WindowsXP”是解决诸如新添加的驱动程序与硬件不相符之类问题的一种方法。用这种方式启动，WindowsXP只恢复注册表项HklmSystemCurrentControlSet下的信息。任何在其他注册表项中所做的更改均保持不变。(7)目录服务恢复模式：不适用于WindowsXPProfessional。这是针对WindowsXPServer操作系统的，并只用于还原域控制器上的Sysvol目录和ActiveDirectory目录服务。(8)调试模式：启动WindowsXP，同时将调试信息通过串行电缆发送到其他计算机。如果正在或已经使用远程安装服务在你的计算机上安装WindowsXP，可以看到与使用远程安装服务恢复系统相关的附加选项。6、如何彻底删除XP现象：我装了WindowsMe和WindowsXP双系统，都是FAT32格式。C盘装WindowsMe，E盘装WindowsXP。昨天，WindowsXP系统丢失了SYSTEM32.DLL，启动不了。于是我在进入WindowsMe系统内，在E盘直接删除WindowsXP。但是，每次开机都出现多系统启动菜单，供选择。我该怎样才可以彻底删除XP？用一张Windows9x/Me的启动盘启动，在“A:”下输入“SYSC:”，给C盘重新传系统即可。7、如何处理WindowsXP不能自动关机现象现象：我的WindowsXP有时候不能自动关闭电脑，请问应该怎么办？安装完WindowsXP之后，有些计算机在单击关闭电脑之后并不能自动关闭，而需像以前的AT电源一样手动关闭。这主要是WindowsXP未启用高级电源管理。修正方法：单击“开始→控制面板→性能和维护→电源选项”,在弹出的电源选项属性设置窗口中，单击“高级电源管理”并勾选“启用高级电源管理支持”。8、如何创建“锁定计算机”的快捷方式因有急事而需要离开，但又不希望电脑进行系统注销，该怎么办？你完全可以通过双击桌面快捷方式来迅速锁定键盘和显示器，且无需使用“Ctrl+Alt+Del”组合键或屏幕保护程序。操作方法：在桌面上单击鼠标右键，在随后出现的快捷菜单上指向“新建”，并选择“快捷方式”。接着，系统便会启动创建快捷方式向导。请在文本框中输入下列信息：rundll32.exeuser32.dll,LockWorkStation，单击“下一步”。输入快捷方式名称。你可将其命名为“锁定工作站”或选用你所喜欢的任何名称，单击“完成”。你还可对快捷方式图标进行修改(我最喜欢的一个是由Shell32.dll所提供的挂锁图标)。如需修改快捷方式图标，请执行下列操作步骤：右键单击“快捷方式”，并在随后出现的快捷菜单上选择“属性”。选择“快捷方式”选项卡，接着，单击“更改图标”按钮。在以下文件中查找图标文本框中，输入She