SPECjbb 分析与使用

一、目的

• Java可运行在不同的操作系统平台上，但不同的Java版本运行在不同的硬件平台上会反映出不同的性能，所以我们要进行不同硬件平台运行Java程序的效率分析

二、SPECjbb 简介

2.1 是什么

SPECjbb官网链接

• SPECjbb2005(Java Business Benchmark)基准测试模拟一个三层架构环境来进行JAVA 应用服务器测试，衡量应用服务器端JAVA 应用性能，在SPECjbb 这个基准测试中，被测产品要运行JVM，模拟一家全球大型零售企业的各种终端销售点请求、在线购买、数据挖掘等日常业务，通过不断增加的业务量来测试系统能够处理的最大值，同时会测试随着业务量增加，系统响应时间的变化，以全面评估运行各项Java业务应用的服务器性能水平，即每秒钟完成多少次JAVA 业务操作(Business Operation Per Second)（吞吐量：单位时间内成功地传送数据的数量），正规SPECjbb2005 测试结果发布必须提供bops 值, 即每秒钟完成多少笔JAVA 业务操作(Business Operation Per Second)，同时要求提供完整的测试环境资料，包括：Java EE应用服务器名称，DB服务器名称，处理器内核数量，Java SE服务器数量等
• SPECjbb2005受TPC-C基准测试的启发，在模式、输入生成和事务概要方面松散地遵循TPC-C规范，SPECjbb2005在单个JVM中运行（尽管基准测试可能会产生几个JVM实例）

2.2 三层客户/服务器模型结构

• SPECjbb 模拟了三层客户/服务器模型结构，所有的三层结构都在一个JVM内实现（尽管基准测试可能会产生几个JVM实例）：第一层是表示层；第二层是业务逻辑层；第三层是数据访问层，简单来说就是用户（客户端输入）、商业应用逻辑、数据库，并将中间层作为主焦点
• 在SPECjbb这样表示：
  第一层是用进程或线程模拟客户系统的随机输入
  第二层是对树结构数据库中的数据进行操作
  由Java类和Java对象形成的树结构模拟第三层的数据库
  用Java类取代数据库中的表table，用Java对象取代数据库中的记录record，这些对象作为Java集合的实例或其他Java数据对象保存在内存中，重点是第二层业务逻辑的处理能力，即考察用Java编写的应用程序运行在某台服务器上所表现出的性能
  ”数据库现在被建模，不是作为在基准本身的代码中实现的BTree结构，而是作为HashMap实现的结构，或者在表上的某些操作需要排序的情况下作为TreeMap实现的结构，其目的是让基准测试反映Java开发人员在提供适当功能的地方使用库的实践，而不是编写自己的代码实现“
  

2.3 特性

1. 一种基于一家全球超市公司的使用模型，该公司拥有处理销售点请求、在线购买和数据挖掘操作的IT基础设施
2. 纯吞吐量度量标准和根据服务级别协议（sla）度量关键吞吐量的度量标准，指定的响应时间从10毫秒到100毫秒不等（性能用两个指标来表示，一个是max jops为纯吞吐量量，一个是critical jops为限制响应时间下的吞吐量量），可以理解为总吞吐量与关键吞吐量
3. 支持多运行配置，使用户能够分析和克服系统堆栈的多个层的瓶颈，包括硬件、操作系统、JVM和应用程序层
4. 使用新的Java 7特性和其他重要的性能元素，包括最新的数据格式（XML）、使用压缩的通信以及具有安全性的消息传递
5. 支持虚拟化和云环境

三、环境说明

• 硬件配置：
  至少需要一台8GB内存的服务器，性能运行建议使用24g及以上
• 软件配置：
  操作系统：JVM7或更高版本可用的任何操作系统上运行，因为SPECjdd的测试工作负载是用Java编写的，需要运行在JVM上

四、TPC-C 简介

4.1 是什么

• TPC（transaction processing performance council）被称为事务处理性能委员会，负责定义诸如 TPC-C、TPC-H&TPC-R 和 TPC-W 基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC-C 于 1992 年 7 月 23 日认可为新的基准测试，是衡量联机事务处理（OLTP，Online Transaction Processing）系统的工业标准，是行业中公认的权威和最为复杂的在线事务处理基准测试。

4.2 TPC-C模型

TPC-C的模拟程序并不针对特定的商业对象，可以模拟含有管理、销售、分发产品、服务的任何工业（例如汽车出租、食物分配、零件供应等），而在TPC-C中描述使用的是一个大型商品批发销售公司，它拥有若干个分布在不同区域的商品仓库，当业务扩展时，公司将添加新的仓库，每个仓库负责为10各销售点供货，其中每个销售点为3000个客户提供服务，每个客户提交的订单中，平均每个订单有10项产品，所有订单中约1%的产品在其直接所属的仓库中没有存货，必须由其他区域的仓库来供货，同时，每个仓库都要维护公司销售的100000种商品的库存记录

4.3 TPC-C指标

TPC-C测试结果主要有两个指标，即流量指标（Throughput，简称tpmC）和性价比（Price/Performance，简称Price/tpmC）
流量指标（Throughput，简称tpmC）：按照TPC组织的定义，流量指标描述了系统在执行支付操作、订单状态查询、发货和库存状态查询这4种交易的同时，每分钟可以处理多少个新订单交易，所有交易的响应时间必须满足TPC-C测试规范的要求，且各种交易数量所占的比例也应该满足TPC-C测试规范的要求，在这种情况下，流量指标值越大说明系统的联机事务处理能力越高
性价比（Price/Performance，简称Price/tpmC）：即测试系统的整体价格与流量指标的比值，在获得相同的tpmC值的情况下，价格越低越好

4.4 TPC-C交易事务

1. 新订单（New-Order）：客户输入一笔新的订货交易
2. 支付操作（Payment）：更新客户帐户余额以反映其支付状况
3. 发货（Delivery）：发货（模拟批处理交易）
4. 订单状态查询（Order-Status）：查询客户最近交易的状态
5. 库存状态查询（Stock-Level）：查询仓库库存状况，以便能够及时补货

4.4.1 新订单（New-Order）

• 事务内容：对于任意一个客户端,从固定的仓库随机选取5-15件商品，创建新订单，其中少订单要由假想操作失败而回滚
• 主要特点：中量级、读写频繁、要求响应快

4.4.2 支付操作(Payment)

• 事务内容：对于任意一个客户端，从固定的仓库随机选取一个辖区及其内用户，采用随机的金额支付一笔订单，并作相应历史纪录
• 主要特点：轻量级，读写频繁，要求响应快

4.4.3 订单状态查询(Order-Status)

• 事务内容：对于任意一个客户端，从固定的仓库随机选取一个辖区及其内用户，读取其最后一条订单，显示订单内每件商品的状态
• 主要特点：中量级，只读频率低，要求响应快

4.4.4 发货(Delivery)

• 事务内容：对于任意一个客户端，随机选取一个发货包，更新被处理订单的用户余额，并把该订单从新订单中删除
• 主要特点：读写频率低，较宽松的响应时间

4.4.5 库存状态查询(Stock-Level)

• 事物内容：对于任意一个客户端，从固定的仓库和辖区随机选取最后几条订单,查看订单中所有的货物的库存，计算并显示所有库存低于随机生成域值的商品数量
• 主要特点：重量级，只读频率低,较宽松的响应时间

五、SPECjbb 基准松散的遵循 TPC-C 规范

• SPECjbb2005受TPC-C基准测试的启发，在模式、输入生成和事务概要方面松散地遵循TPC-C规范，其中在事务方面增加了一种Cust Report（客户报告），共 5+1=6 种事务
• 用以下Java 类取代数据库中的表 table
  WareHouse.java 仓库
  District.java 区域/地区
  Customer.java 客户，客户购买商品，客户属于某个district
  Item.java 产品
  Stock.java 库存
  Order.java 订单
  OrderLine.java 订单详情
  NewOrder.java 订单在仓库、区域关联表
  History.java 历史记录
• 最小数据库要求：warehouse仓库>= 8；District地区>=5；Customer用户>=30
  
  

5.1 SPECjbb 中间结果

事务	Count	Total	Min	Max	Avg	Heap Space
New Order：						total
Payment：						used
OrderStatus：
Delivery：
Stock Level：
Cust Report：

throughput = …

表示有关 线程/仓库 在该点完成的信息：
每种事务类型的数字结果（0-5）；
Count：计数是在运行此仓库数期间完成的每种类型的事务数；
Total：总计是此类事务中花费的总时间，因此 Avg 为"总计/计数"；
Min：最小是每种事务的最小响应时间；
Max：最大是每种事务的最大响应时间；
Avg：平均是每种事务的平均响应时间；
Heap Space：堆大小，分为 total 总大小和 used 已使用大小
throughput：结果是计数 Count 除以秒数的总和

六、SPECjbb 原理分析

6.1 组件等说明

• SPECjbb2005 基准的组件由控制器 Controller (Ctr)、事务注入器 Transaction Injector(s) （TxI）和后端 Backend(s) （BE）组成，这三个组件可以在一个JVM里运行，也可以分别运行在不同的JVM中
  控制器：控制文件输出；事务注入器：发出请求，跟踪响应时间；后端：字节码转换为机器指令
• 其他说明：
  SPECjbb 是完全自包含和自驱动的（生成自己的数据，生成自己的多线程操作，并且不依赖于JRE以外的任何包，只有jbb.jar和check.jar）；
  SPECjbb 2005 当前Java级别为 Java5.0，基准测试包括 JDK 语言级别的几个特性，一些集合数据结构已成为通用的，源代码包含自动装箱和枚举类型的几种用法；
  事务日志通过使用 Java5.0 的 JAXPXML 功能构建和编写DOM对象来完成；
  还可以部署几个JRE实例，每个实例在自己的数据表上独立地处理事务负载

6.2 两个性能指标

• SPECjbb2005 bops：业务操作/秒，通过从预期仓库峰值数对 SPECjbb2005 运行中的总交易速率进行平均计算
• SPECjbb2005 bops/JVM：每个JVM 实例的平均吞吐量
• SPECjbb2005 bops 指标测量所有 JVM 在基准运行中实现的总吞吐量；SPECjbb2005 bops/JVM 反映了单个 JVM 对总体指标的贡献，因此是单个 JVM 性能和扩展的度量
• 指标的计算取决于预期仓库峰值，而不是实际仓库峰值
  因为随着开发系统的预期峰值越来越大，特别是在测量周期之外没有 System.gc() 调用的话，在任何给定系统上可能出现 SPECjbb2005 峰值运行的仓库数量差异更大，为了增加可预测性，SPECjbb2005 bops 指标使用预期仓库峰值进行计算

6.3 运行原理

• SPECjbb 在运行时利用多个特殊数据组和多个线程，每个数据单元分别是一个 warehouse 仓库，存储在多个集合（HashMap、TreeMap）的许多对象中，每个线程均表示一个将事务请求记入仓库的活动用户，基准运行从一个仓库开始，用户发起一组操作，例如下新订单或请求查询现有订单的状态，公司内部会生成其他操作，例如处理交货订单、输入客户付款、查询库存状态，以及请求提供有关给定客户最近活动的报告，然后增加仓库数，使服务器的处理器容量饱和，在仓库数增加时，线程数也会随之增加，基准的结果（即两个指标）描述了服务器的吞吐量：SPECjbb2005 bops(业务操作/秒，通过从预期仓库峰值数对 SPECjbb2005 运行中的总交易速率进行平均计算)；每个JVM 实例的平均吞吐量，SPECjbb2005 bops/JVM
• 主基准测试循环由一组用户线程运行，每个线程运行 TransactionManager.go()，由运行 Company.displayResultTotals 的主线线程控制。每个用户线程都在运行while循环，执行一系列随机事务，先对仓库进行30秒的测量，直到达到预期的峰值，然后每个仓库测量240秒（4分钟），每个线程收集和写入事务数据以供将来参考。在具有多个仓库的单个JVM运行中，启动时间是测量周期的一部分，由于测量间隔较短，在预期仓库峰值之前可能会看到不稳定的结果
• 以上为单JVM模式，如果是多JVM模式：
  则有一个 3 秒的初始爬升周期，以确保在开始测量事务速率之前所有线程都在运行，还有一个20秒的下降周期。
  多 JVM 模式本人猜测为顺序运行，具体结果有待商榷
  rampup and rampdown specify rampup and rampdown for multi-jvm mode only.(seconds)：rampup和rampdown仅为多 JVM 模式指定rampup和rampdown（秒）

6.3.1 单 JVM 度量计算

• 点表示在给定数量的仓库中完成工作的测量周期，完整的基准测试运行由一系列测量点组成，这些测量点的仓库数量不断增加（因此线程数量也不断增加）
• 所有点运行，即从 1 到 MaxWh（SPECjbb.props 仓库中仓库的 input.ending_number 指定MaxWh最大仓库数量，默认为8），必须至少运行从 1 到 8 的所有点，否则提示：INVALID：at least the points from 1 to 8 are needed for a publishable run. （无效：可发布的运行至少需要1到8之间的点），但是不代表没有运行结果，只是说结果无效不被认可
  对于从 1 到预期峰值 M 的仓库数量（预期观察到峰值的仓库数，由 SPECjbb.prop 中的非零input.expected_peak_warehouse指定，或定义为 Runtime.getRuntime.availableProcessors()（如果属性设置为 0），到达仓库预期峰值数之前每个仓库为 30 秒的测量周期，达到仓库预期峰值数之后，测量周期为240秒（4分钟），所有 JVM 实例一起运行这些测量周期
• 从M到 2*M，包含仓库的所有点的所有实例的总吞吐量，此平均值为所取结果
• 不运行到最多 2*M 仓库的所有点的系统的结果仍被视为有效
• 对于范围 M+1 到 2*M 的所有缺失点，在指标计算中，吞吐量被视为0
• 用户可以配置要运行的应用程序实例数。当选择多个实例时，将同时运行多个实例，最终度量值是各个实例的度量值之和。使用Socket本地套接字通信和控制器同步多个应用程序实例
• SPECjbb 结果图为在水平轴上的仓库和垂直轴上的吞吐量以及每个 JVM 的所有测量点的吞吐量图。报告从 1 到最大值 8 或 MaxWh 的所有点，M+1 到 2*M 范围内的缺失点将报告吞吐量为0

七、SPECjbb 源码概述

7.1 运行简述

1. 检查JVM环境；
2. 从SPECjbb.props中加载属性，并获取基本配置属性；
3. 指明输出结果路径；
4. 检查jar文件；
5. 检查运行是否有效；
6. 模拟执行：
   模拟建立Company公司，加载各仓库，每增加一个仓库则增加一个线程，获取前后测量时间，计算仓库最小最大交易量，获取不同事务对应结果，获取吞吐量
7. 生成报告：
   包含综合吞吐量SPECjbb2005 bops与SPECjbb2005 bops/JVM；结果有效性判断；软硬件信息；测试汇总

7.2 结构说明

• jbb.jar：主要处理活动以及基准的后期处理相关代码
• check.jar：有效性检查和验证代码
• /src/spec/ reporter：包含SPECjbb2005 reporter的文件，它将基准输出格式化为各种可能的报告
• /src/spec/jbb：包含主基准代码
• /src/spec/jbb/validity：包含对JVM与语言规则的一致性进行有限检查的文件
• /src/spec/jbb/infra/Util：包含定义事务日志对象的代码，这些对象被实现为 XMLDOM 对象

7.3 类图表示

7.4 相关类说明

• 数据库是一个 Company 的数据库，由定义的类的实例 Company.java 表示；有不同数量的仓库对象，如所定义的仓库 Warehouse.java，每一个仓库对应不同地区 District.java，地区有相关地址 Address.java
• Company 有三个主要的数据表，Item table、CustomerTable 和 CustomerbyLastNameTable。每个仓库对象都有自己的 StockTable 和HistoryTable。每个地区都有自己的 OrderTable 和 NewOrderTable。所有表都是 JBBDataStorage 或 JBBSortedDataStorage 的实例
• 模拟 Company 数据库的表中字段的底层数据结构可以在Item.java, Stock.java, Customer.java., Address.java中查看
• Order.java 以及 NewOrder.java 定义表示驱动事务订单的订单对象
• 有 5+1 种类型不同的交易事务在 NewOrderTransaction.java，OrderStatusTransaction.java，DeliveryTransaction.java，PaymentTransaction.java，StockLevelTransaction.java，CustomerReportTransaction.java 中定义

7.5 属性文件

• SPECjbb2005 将两个属性文件作为输入：控件属性文件和描述性属性文件。控件属性文件用于修改基准的操作，例如更改测量间隔的长度。描述性属性文件用于记录正在测试的系统，此文件是可发布结果所需的，并反映在输出文件中，描述性属性的值不会影响工作负荷

7.5.1 描述性属性文件

• 描述性属性文件的名称在控件属性文件中指定，使用input.include_file。包中包含的示例控件属性文件中分布的默认名称是 SPECjbb_config.props

7.5.2 控件属性文件

• 控件属性文件的默认名称为 SPECjbb.props，但可使用 -propfile 命令行选项用其他名称覆盖
• 控制属性文件允许修改三种不同的基准行为：运行长度、仓库序列和垃圾回收行为。基准测试可以试验任何这些行为，但对于可发布的结果，对修改有限制。控件属性文件还包含指定基准名称的属性，但不应更改此属性

7.5.2.1 运行长度

• The length of the run is controlled by the properties: input.per_jvm_warehouse_rampup, input.per_jvm_warehouse_rampdown specifies, in seconds the ramp up and ramp down time for each JVM instance, input.ramp_up_seconds, input.measurement_seconds, and input.expected_peak_warehouse. input.ramp_up_seconds specifies, in seconds, the length of each warehouse interval before the expected_peak_warehous, and input.measurement_seconds specifies, in seconds, the length of each warehouse from there on… For a result to be publishable input.ramp_up_seconds must be 30 and input.measurement_seconds must be 240.
• 简单来说就是 input.starting_number_warehouses，input.increment_number_warehouses，input.ending_number_warehouses，input.expected_peak_warehouse分别表示起始仓库数量、仓库增量、结束仓库数量、预期仓库数量峰值，到达仓库预期峰值数之前每个仓库为input.ramp_up_seconds = 30 秒的测量周期，达到仓库预期峰值数之后，测量周期为 input.measurement_seconds = 240s ，即4分钟；如果是多 JVM ，则有一个 input.per_jvm_warehouse_rampup 初始爬升周期，以确保在开始测量事务速率之前所有线程都在运行，还有一个 input.per_jvm_warehouse_rampdown 下降周期

7.5.2.2 仓库序列

• Warehouse sequence may be controlled in either of two ways. The usual method for specifying warehouse sequence is the set of three properties, input.starting_number_warehouses, input.increment_number_warehouses, and input.ending_number_warehouses , which causes the sequence of warehouses to progress from input.starting_number_warehouses to input.ending_number_warehouses, incrementing by input.increment_number_warehouses. The alternative method of specifying warehouse sequence is input.sequence_of_number_of_warehouses, which allows specification of an arbitrary list of positive integers in increasing order. For a publishable result the warehouse sequence must begin at 1 and increment by 1 . See Section 4.1 for a discussion of requirements on the total number of warehouses that must be run.
• 简单来说就是指定仓库序列的常用方法是三个属性（input.starting_number_warehouses、input.increment_number_warehouses 和 input.ending_number_warehouses），这会导致仓库序列从 input.starting_number_warehouses 到input.ending_number_warehouses，增量为 input.increment_number_warehouses。指定仓库序列的替代方法是input.sequence_of_number_of_warehouses，它允许按增加顺序指定正整数的任意列表，对于可发布的结果，仓库序列必须从 1 开始，然后递增 1

7.6 结果文件

• 基准运行将生成一个原始文件预 JVM 实例，原始文件将放在结果目录的子目录中，其名称为SPECjbb.xxx其中 xxx 是数字后缀。该子目录中的 SPECjbb.y.raw（y是数字，每个 JVM 实例有一个）文件包含来自属性文件的所有输入和测试结果，报告器工具使用此文件生成所有其他文件格式
  
  

八、影响测试性能的关键

1. JVM
2. JIT（Java程序最初是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器）
3. Garbage Collection（SPECjbb2005 现在不包括基准的主要部分中的 System.GC 调用，其目的是反映长时间运行的应用程序的行为，而不是周期性的中断System.GC回调）
4. Thread
5. 操作系统的内核处理
6. CPU的整型处理能力、Cache的大小、内存大小和结构
7. 服务器对称多处理SMP的线性扩展能力（复用处理器的能力）

九、单JVM默认测试

本人使用虚拟机进行以下测试，结果存在误差

9.1 查看 SPECjbb.props 默认配置属性

#input.expected_peak_warehouse =0没有指定预期仓库峰值数量，默认为4

input.starting_number_warehouses=0

input.increment_number_warehouses=1

input.ending_number_warehouses=8

input.sequence_of_number_of_warehouses=1 2 3 4 5 6 7 8

9.2 执行命令