本文介绍了SPECjAppServer2004——新的行业标准基准测试，它用于度量J2EE硬件和软件平台的性能和可伸缩性。SPECjAppServer2004是一种全新的基准测试，它与2002年发布的SPEC J2EE基准测试没有可比性。本文讨论了该基准所构建的业务域和workload应用程序，以及基准设计和架构。作者还解释了基准指标的含义，讨论了该基准测试的各种用途，并提供了一些到辅助信息的链接。

简介

　　SPECjAppServer2004是一个新的行业标准基准测试，它用于度量基于Java 2 Enterprise Edition (J2EE)技术的应用服务器的性能和可伸缩性。SPECjAppServer2004是由SPEC的Java小组委员会（包括BEA、Borland、Darmstadt University of Technology、Hewlett-Packard、IBM、Intel、Oracle、Pramati、Sun Microsystems和Sybase）开发出来的。值得注意的是，虽然SPECjAppServer2004中的一些部分看起来与SPECjAppServer2002类似，但是SPECjAppServer2004更为复杂，与SPECjAppServer的以前版本相比具有实质区别。它实现了新的增强的workload，该应用程序涉及到所有主要的J2EE平台服务，包括：

• Web容器，包括servlet和JavaServer页面
• EJB容器
• EJB 2.0容器托管持久性
• JMS和消息驱动bean
• 事务管理
• 数据库连通性

　　此外，SPECjAppServer2004可以测试构成应用环境的底层基础架构的所有部分，包括硬件、JVM软件、数据库软件、JDBC驱动程序和系统网络。服务器供应商可以使用SPECjAppServer2004度量、优化和展示产品的性能和可伸缩性。他们的客户可以使用它来更好地理解有关开发当前的J2EE应用程序的调整和优化问题。

SPECjAppServer2004业务模型

　　SPECjAppServer2004 workload基于一个声称足够大、足够复杂、足以代表现实世界电子商务系统的分布式应用程序。基准的设计人员选择了制造商、供应链管理和订单/库存系统作为业务问题的“原型”进行建模。这是一个具有说服力的分布式问题，它是重量级和任务关键型的，并且需要使用一个强大而具有可伸缩性的基础架构。更重要的是，它需要使用中间件服务，包括对象持久性存储、缓存、分布式事务、集群、负载均衡、资源入池、异步消息传递、动态Web页面生成，以及其他。SPECjAppServer2004基准的测试重点就是这些应用服务器的服务。

　　SPECjAppServer2004 workload是以一个汽车制造商为模型构建的，该制造商的主要客户是汽车经销商。经销商使用一个基于Web的用户界面浏览汽车目录、购买汽车、出售汽车，并跟踪经销商产品清单。

　　如图1所示，SPECjAppServer2004的业务模型由5个域组成。

• 客户域(customer domain)：处理客户订单和交互。
• 经销商域(dealer domain)：提供一个到客户域中的服务的基于Web的接口。
• 制造域(manufacturing domain)：执行“准时生产”(just-in-time)制造操作。
• 供应商域(supplier domain)：处理与外部供应商的交互。
• 公司域(corporate domain)：管理所有的客户、产品和供应商信息。

图1. SPECjAppServer2004业务模型

　　图2 显示了这些域中运行的一些典型事务（经销商域被省略了，因为它本身并没有新的服务）。

图2. SPECjAppServer2004业务域

图中文字：

　　客户域：订单输入应用程序：-下订单；-获取订单状态；-获取客户状态；-取消订单。

　　公司域：客户、供应商和部件信息：-注册客户；-确定折扣；-核查信用。

　　制造域：制造应用程序：-确定工作订单时间表；-更新工作订单；-完成工作订单；-创建大的订单。

　　供应商域：与供应商交互：-选择供应商；-发送购买订单；-交付购买订单。

　　我们将按照基准文档中的描述，简要介绍这5个域：

客户域

　　客户域驻留了一个订单输入应用程序，它提供了一些典型的在线订单功能。包括下新订单、查看某个订单或给定客户的所有订单的状态、取消订单等等。当收到客户的订单后，就要向公司域发送一个请求，核查客户的信用。此外，还要计算适当的折扣。超过100辆汽车的订单就称为大订单。

经销商域

　　经销商域驻留了一个称为经销商应用程序的Web应用程序，它提供了一个到客户域中服务的基于Web的接口。它允许客户（在本例中是汽车经销商）了解他们的账单和经销商产品清单、管理购物车，以及购买和出售汽车。

制造域

　　制造域驻留了一个制造应用程序，它将汽车制造厂的生产线活动建模。有两种类型的生产线，分别称为规划生产线和大订单生产线。规划生产线按时间表运行，生产预定数目的汽车。大订单生产线只在客户域收到大订单时才运行。制造域的工作单元是工作订单。每个工作订单对应于特定数目的特定型号的汽车。当建好工作订单后，相应类型汽车的部件报单就被收回，所需的部件也会从库存清单中扣除。当汽车到达装配线后，就会更新工作订单状态以反映进度。工作订单完成后，它就会被标示为“已完成”，并更新库存清单。当部件的库存用完后，就要联系供应商，并发出购买订单(PO)。这是通过连接到供应商域而实现的，供应商域负责与外部供应商进行交互。

供应商域

　　供应商域负责与外部供应商进行交互。它基于需要定购的部件决定选择哪家供应商、要求的时间，以及供应商的报价。公司会向选中的供应商发送一个购买订单(PO)。购买订单中会包括要购买的各种部件的质量、交付地点以及必须交付的日期。当收到供应商的部件时，供应商域会向制造域发送一条消息以更新库存清单。

公司域

　　该域管理客户、部件和供应商的总列表。所有客户的信用信息（包括信用限制）都保存在公司域中的一个数据库中。这是为了提供最大的安全性和保密性。

SPECjAppServer2004应用程序设计和Workload

　　上述5个域中所有的活动和过程都是通过单一的J2EE应用程序实现的，该应用程序由J2EE组件（Enterprise JavaBean、servlet和JavaServer页面）装配而成，部署在一个运行在System Under Test (SUT)上的应用服务器上。唯一的例外是与供应商的交互，这是使用一个称为Supplier Emulator的独立Web应用程序实现的。该应用程序部署在一个专用机器上的支持Java的Web服务器上。它为供应商域提供了一种模拟向供应商发送/从供应商接收订单的过程的方法。

　　Workload生成器是使用一个称为SPECjAppServer Driver的多线程Java应用程序实现的。该应用程序被设计为可以使用任意数量的Java虚拟机运行在多个客户机上，以便它不具有固有的可伸缩性限制。它由两个组件构成：manufacturing driver和DealerEntry driver。manufacturing driver驱动制造域中的生产线（规划生产线和大订单生产线），并运行制造应用程序。它通过RMI（Remote Method Invocation，远程方法调用）接口与SUT进行通信。DealerEntry driver模拟汽车经销商，使用经销商域中的经销商应用程序访问客户域中的订单输入应用程序的服务。它通过HTTP与SUT进行通信，并运行经销商和订单输入应用程序，使用3个称为业务服务的操作：

• 购买：下新车辆的订单。
• 管理：管理客户产品清单（卖出车辆和/或取消打开的订单）。
• 浏览：浏览车辆目录。

　　每个业务事务都模拟了特定类型的客户机会话，每种会话都涉及与服务器的多次通信。例如，浏览事务导航到车辆目录Web页面，然后总共翻页13次——10次发出，3次返回。驱动程序基于表1中的混合比例选择业务事务。基准测试中的实际混合比例必须使每种业务事务落在规定的混合比例左右5%的范围内。例如，浏览事务的变化范围是总体的47.5%到52.5%。驱动程序检查并报告是否满足了混合要求。

　　使用关系数据库管理系统(DBMS)进行数据持久性存储，所有的数据访问操作都使用实体bean，这些bean映射到SPECjAppServer数据库中的表格。数据访问组件遵循VLDB 2002文件Improving Data Access of J2EE Applications by Exploiting Asynchronous Messaging and Caching Services (PDF)（通过采用异步消息传递和缓存服务改善J2EE应用程序的数据访问）中的指导原则，以便提供最大的可伸缩性和最优的性能。

　　SPECjAppServer2004中的跨域通信是通过采用了Java Message Service (JMS)和消息驱动bean (MDB)的异步消息传递实现的。具体来说，下大订单和履行大订单（需要客户域与制造域之间的通信）是异步实现的。另一个例子是下供应商购买订单和交付供应商购买订单，需要制造域与供应商域之间的通信。后者是根据VLDB 2002文件Improving Data Access of J2EE Applications by Exploiting Asynchronous Messaging and Caching Services (PDF)中解决性能和可靠性问题的提议实现的。

　　基准测试的吞吐量是由经销商和制造应用程序的活动决定的。两个应用程序的吞吐量都与所选的事务注入率(Transaction Injection Rate)直接相关，后者确定了DealerEntry driver所生成的业务事务的数量，以及每个单位时间manufacturing driver所安排的工作订单的数量。基准测试后所得到的汇总性能指标称为JOPS，它表明了测量期间每秒的（成功）应用服务器操作数(JAppServer Operations Per Second)的平均值。对SPECjAppServer2004的EJB、数据库模型和所实现的事务等方面的细节感兴趣的读者，可以参考基准测试设计文档。

　　为了确保SPECjAppServer2004结果以正确的方式获得，并且所有的要求都得到满足，驱动程序通过在运行开始和结束时对SUT调用特定的组件来显式地进行审计检查。驱动程序将审计结果归入运行结果中。要查看驱动程序执行的单个审计活动的列表，请参见基准测试运行和报告规则。

标准的workload与分布式的workload

　　为了满足不同客户的要求，SPECjAppServer2004可以在标准和分布式两种模式下运行。SUT由一个或多个节点组成，具体数量由实现者自由选择。数据库和J2EE服务器的总数可以映射为所需的节点。但是，除了WAN/LAN流量的固有消除，不要专门使用数据库和J2EE服务器协同定位来实现。

　　在标准版的workload中，允许将全部的4个域组合到一起。这意味着基准测试实现者可以选择运行单个的部署单元来访问包含所有域的表格的单个数据库。但是，基准测试实现者可以使用一个或多个数据库实例将这些域分离到他们的部署单元中去。

　　分布式版的workload是为了在（SPECjAppServer2004对其建模的）全球性企业采用异构资源管理程序跨业务域执行业务事务的场景中，度量应用程序的性能。在该模式下，workload要求每个域都有单独的部署单元和单独的DBMS实例。针对跨多个域的业务服务，要求服从XA的可恢复两阶段提交（参见The Open Group XA Specification）。两阶段提交的配置要求以一种支持异构系统的方式进行。即使实现很可能对所有域使用同一个资源管理器，J2EE服务器和资源管理器也不能利用对异构资源管理器的了解优化两阶段提交。

结束语

　　SPECjAppServer2004提供了一个逼真的workload来度量J2EE硬件和软件平台的性能和可伸缩性。可以将其用于以下目的：

• 比较互相竞争的J2EE硬件和软件平台的性能和可伸缩性。
• 研究J2EE平台的不同配置选项和调整参数对系统的总体性能的影响。
• 对J2EE平台进行压力测试，并分析测试结果以找出潜在的瓶颈。
• 作为一个示例（蓝图）应用程序，演示构建可伸缩的应用程序的J2EE最佳实践和设计模式。