.        select next row（下一值取值方式）

l        Sequential（顺序）：Vuser按照顺序从数据表中取值，每次当Vuser访问数据表，都返回下一个可用的数据，如果没有足够的数据，VuGen将从数据表的第一行重新开始取值。这种方式强调虚拟用户的一致性，每个用户运行到该点取值是一致的

l        Random（随机）

每次Vuser访问数据表时都分配一个随机的值

l        Unique（唯一）

唯一的数，为每个Vuser的参数分配唯一的值。与sequential相比，Unique强调的是用户间的差异性，每个用户取到的参数都不一致

2.        Update value on（更新方式）

l        Each iteration：每次迭代都取一个新的值，如果在脚本的一次迭代中，该参数出现两次也只取同一个值

l        Each occurrence：每次遇到参数都取一个新值，如果在脚本的一次迭代中，该参数出现两次，那么两次都取不同的值

l        Once：在一个Vuser中参数都取相同的值（不管几次迭代）

3.        组合取值说明表

参数取值和更新方式列表
update method （更新方式）	数据分配方法
	sequential（顺序）	random（随机）	unique（唯一）
Each iteration （每次迭代）	对于每一次迭代，Vuser都从数据表中取下一个值	对于每一次迭代，Vuser都从数据表里取一个新的随机值	对于每一次迭代，Vuser都会从数据表里取下一个唯一值
Each occurrence (每次遇到)	即使在一次迭代中，每次遇到参数，Vuser都会从数据表中取下一个值	即使在一次迭代中，每次遇到参数，Vuser都会从数据表中取一个新的随机值	即使在一次迭代中，每次遇到参数，Vuser都会从数据表中取一个新的唯一值
once （一次）	对于每个Vuser，第一次迭代分配的值和接下来的迭代取相同的值	对于每个Vuser，第一次迭代分配的随机值和接下来迭代取相同的值	对于每个Vuser，第一次迭代分配的唯一值和接下来的迭代取相同的值

4.        Unique参数取值说明

Select next row = unique需要选下面两个内容

l        When out of value（当数据表的值不够的时候所做操作）

Abort user（中止运行）：停止运行

Continue with last value（取最后一个值）：Vuser取最后一个值

Continue in a cyclic manner（循环取值）：Vuser从属于他的数据表中的第一个取值开始循环取值

l        Allocate Vusers value in the Controller（为Vuser分配参数块）

Automatically allocate block size（自动分块）：系统自动为参数分块大小

自动分块示意图：假设一个Vuser执行完迭代需要4个值

A1	A2	A3	A4	A5	A6	A7	A8	…	An	An+1
Vuser1				Vuser2				…	Vuser n		Vuser n+1

1)       会按照排队的方式分配参数

2)       块的大小为一个Vuser运行完毕所需要的参数

3)       Vuser分到的参数不够，将在自己分的块中进行取值：例如：Vuser n只分到两个参数，Vuser n会按照when out of value的方式取值，如果是Continue with last value，Vuser n的参数取值是An，An+1，An+1，An+1，如果选择的是Continue in a cyclic manner，Vuser n的参数取值是An，An+1，An，An+1（块内循环）

4)       Vuser n+1因为没有分到参数会报错

5)       所需参数总数 块大小* Vuser个数（块大小计算，Each iteration（每次迭代）则=迭代次数，Each occurrence（每次遇见）则=迭代次数*一次迭代出现次数）

 

Allocate ** values for each Vuser（分配**块给每个Vuser）：手动分块

手动分块示意图：假设一个Vuser执行完迭代需要4个值，手动分块块大小为3

A1	A2	A3	A4	A5	A6	A7	A8	A9	…
Vuser1			Vuser2			Vuser3			…

1)       会按照分块的方式分参数

2)       块大小为设定大小

3)       Vuser分到的参数不够，将在自己分的块中进行取值：例如：因为每个Vuser需要四个参数，所以每个Vuser参数都不够，则Vuser2为例，如果选择的是Continue with last value，Vuser 2的参数取值是A4，A5，A6，A6，如果选择的是Continue in a cyclic manner，Vuser 2的参数取值是A4，A5，A6，A4（块内循环）

4)       所需参数总数手动分配块大小* Vuser个数

注：在controller设置duration的情况下，自动分块的分块方式有所变化，块大小=我们输入的参数总数/ Vuser的个数，其他处理方式和手动分配块大小一致

loadRunner监控windows resources提示“拒绝访问”的解决方法：
1.在loadrunner所在机子上启动服务：Remote Procedure Call(RPC)和Remote Registry Service

2.开始>运行>\\192.168.200.211 (你要监控的机子的ip)，输入管理员用户名和密码，可以访问到被监控机子的一些资源。

3.完成1，2操作后仍检测不到数据，不妨试试：windows resources统计图>右键>add measurement>delete再重新add;

4.如果仍旧检测不到数据，则点击windows resources统计图>右键>configure..>点击ok。 


5.有的人可能是因为不小心点击了“统计图>右键>freeze”才看不到数据的。这个操作的意思是：把这个统计图给冻结了，所以你当然就看不到后来的数据了。怎么办呢?再次点击“统计图>右键>freeze”就可以取消冻结了。过几秒后，数据就出来了。

昨天项目上线测试发生了Out of Memory的JVM错误，导致系统down掉并且服务器文件系统撑爆。检查原因是出现过多内存泄漏,系统的可用内存和性能持续下降；最终将导致内存不足(OutOfMemory)。我们开发用的是IBM WebSphere平台，在websphere/AppServer下生成大量javacore*、heapdump*之类的文件，致使websphere的垃圾回收功能失败而导致。其中，javacore文件是关于cpu的，heapdump文件是关于内存的。

生产环境是ibm小型机，按照手册修改了：应用程序服务器 > server1 > 进程定义 > Java 虚拟机，将"最大堆大小（默认为256）"改为768或1024以上。删除文件系统中的javacore*，heapdump*后基本恢复正常。分析原因，一是JVM设置问题，二（最终原因）程序不够健壮，很多资源没有即时释放导致资源撑爆。尤其是数据库连接资源。以前也遇到过进程挂起的情况，与此次不同，进程挂起主要原因是SQL查询不能及时返回结果导致页面一直等待资源返回而挂起（suspend）。三是产生大数据量的结果集返回结果。一直怀疑我们用的数据结构不够合理，但是也没有尝试修改。

总结一下：

关于架构应该使用健全的模式，使用资源后要及时释放和回收垃圾；

尽量采用分布式的结构，类似MVC模式；

努力从程序上解决根本问题。

附：转载

WebSphere应用服务器内存泄漏探测与诊断工具

级别: 中级 李 学朝 (lixuec@cn.ibm.com), 高级软件工程师，IBM中国软件开发中心

2006 年 11 月 21 日

本文介绍了如何在WebSphere应用服务器中实现应用程序内存泄漏的探测，并且针对IBM所提供的系列分析与诊断工具，给出了具体的配置步骤和使用最佳实践。
引言

内存泄漏是比较常见的一种应用程序性能问题，一旦发生，则系统的可用内存和性能持续下降；最终将导致内存不足(OutOfMemory)，系统彻底宕掉，不能响应任何请求，其危害相当严重。同时，Java堆(Heap)中大量的对象以及对象间之复杂关系，导致内存泄漏问题的探测和分析均比较困难，采用相应的辅助工具是很必要的。

WebSphere应用服务器提供了系列针对内存问题的探测和分析诊断工具，这些工具可以帮助用户进行内存问题的及时探测，保证系统在发生OOM之前，用户可以在无须进行复杂分析的条件下，预知在其部署的应用中是否存在内存泄漏的问题。如果确有内存泄漏现象发生，WebSphere还提供了相应的工具，可以帮助用户进行分析诊断，从而找到内存泄漏的真正原因。

1. 内存泄漏探测和诊断步骤

实践中，我们可以采用以下的步骤来处理内存泄漏的问题：

(1) 首先，在WebSphere中我们启用实时探测内存泄漏工具, WebSphere性能诊断顾问会对内存泄漏提前发出警告信息。

(2) 启用WebSphere自带的Tivoli性能查看器监视系统的JVM使用状况，确定内存泄漏是否正在发生。

(3) 根据需要，生成详细内存回收日志，使用PMAT工具分析并确定泄漏的时间，周期等。

(4) 生成单个或者多个Heapdump文件，选用MDD4J进行分析诊断，找到内存泄漏的真正原因。

(5) 提交开发部门进行代码修复，然后重新部署到WebSphere应用服务器。

接下来的部分，我们针对每个环节的配置和工具使用进行阐述。

2．WebSphere应用服务器中内存泄漏的探测工具

2.1 性能诊断顾问介绍

性能诊断顾问(Performance and Diagnostic Advisor)，在WebSphere应用服务器6.0.2版本之前称为运行时性能顾问（Runtime Performance Advisor）。该工具可以周期性的检查WebSphere的设置，并给出调整的推荐值。自WebSphere应用服务器6.0.2版本开始，该工具实现了一种轻量级的内存探测机制，可以非常容易的帮助用户探测是否在系统中存在内存泄漏问题，并提前通过日志和管理控制台进行通知。这样就给用户以足够的时间采取必要的措施防止系统宕掉，同时可以收集或生成相关的文件以进行离线的分析，来查找泄漏的根本原因。

2.2配置

可以在WebSphere应用服务器的管理控制台中启用性能诊断顾问

(1) 访问管理控制台 －>服务器－> 应用程序服务器。

(2) 选择所要配置的服务器。

(3) 在性能区域，选择性能和诊断顾问程序配置。

(4) 如图所示，有两个Tab, 运行时和配置。区别在于，运行时里面的内容无须重启服务器就可以生效，但下次重启服务器的时候，这些配置也会丢失。配置Tab里面的内容只有在服务器重启后才生效，而且配置的内容也会一直存在，除非再次登陆并去掉所选项。

（5）在其他属性区域，点击性能和诊断建议配置，确保内存泄漏规则处于运行状态（绿色箭头）。

2.3 查看泄漏警告信息

WebSphere性能诊断顾问输出信息可以显示在WebSphere的管理控制台，并记录在WebSphere应用服务器的SystemOut.log日志文件里面。

(1) SystemOut.log日志

 [8/31/06 13:21:43:545 CST] 00000010 TraceResponse W   TUNE9001W:  Heap
 utilization patterns indicate that you may have a memory leak
Additional explanatory data follows.
Data values for free memory between 8/31/06 1:20 PM and 8/31/06 1:21 PM were
consistently below minimum required percentage.

（2） 管理控制台

－登陆管理控制台->故障诊断 ->运行时消息 ->点击运行时警告

3. Java 虚拟机概要分析和详细垃圾回收

进一步检测是否有内存泄漏的发生，以及泄漏发生的时间，周期和速度，我们可以启用Java虚拟机中的详细垃圾回收，然后分析相应的日志。 WebSphere应用服务器6.1使用了Java SDK5.0， 在Window, Linux, AIX, i5/OS,z/Linux 和z/OS上使用了IBM的JAVA虚拟机, 在Solaris和HP-UX上使用Sun的JVM。Java 虚拟机概要分析工具接口(Java Virtual Machine Tool Interface，JVMTI)支持从运行应用程序服务器的 Java 虚拟机（JVM）收集信息（如，关于垃圾回收的数据、对象利用和线程状态）并且支持更全面的性能分析。一旦启用了 JVMTI，可以使用 PMI 定制选项来启用所选统计信息以收集特定数据。

3.1启用 Java 虚拟机概要分析和详细垃圾回收配置步骤

配置步骤：

1. 在控制台导航树中单击服务器 > 应用程序服务器

2. 单击选择所需应用程序服务器。

3. 在"服务器基础结构"下，单击 Java 和进程管理-> 进程定义。

4. 在"其他属性"下，单击 Java 虚拟机。

5. 选中配置Tab的详细垃圾回收选项。

6. 在通用 JVM 参数字段中输入 -agentlib:pmiJvmtiProfiler。

注: WebSphere6.1中，JVM概要分析接口改为Java Virtual Machine Tool Interface (JVMTI)。之前版本是JVMPI。如果需要JVMPI的时候，也可以此处输入-XrunpmiJvmpiProfiler。另外，启用JVMTI接口对性能影响较大，尽量避免在生产环境中使用。

7．点击应用或者确定。

8. 单击保存按钮。

9．重启WebSphere应用服务器。

3.2 GC数据分析工具PMAT

在WebSphere应用服务器的日志目录下，native_stderr.log文件就是我们需要的内存回收分析文件。我们推荐使用IBM Pattern Modeling and Analysis Tool for Java Garbage Collector 工具，简称PMAT。 PMAT工具解析JAVA SDK的详细内存回收(GC)日志，并提供统计信息，图表，分析并推荐Java堆配置。PMAT提供了丰富的图形界面来显示Java堆的使用状况，从而更轻松地判断是否有内存问题发生。该工具可以从IBM的alphaWorks网站下载，只有英文版。

我们可以把GC文件从服务器上下载到PMAT所在机器，然后根据WebSphere的平台选择打开相应的GC文件进行分析。下面是一个GC日志片断，手动分析是比较费劲，而且需要深入了解JVM相关知识。

PMAT在分析GC日志后，给出一个总结。下图为例，我们可以看出GC对系统性能的影响，以及完成的垃圾回收次数等，并且我们可以看出工具给出的推荐(Recommendations)显示系统的Java堆使用情况是持续增加的。

进一步，我们可以查看GC的详情，点击Analysis菜单，然后选择Graph View All，我们就可以根据需要选择所要查看的曲线。如图所示，红色曲线代表已使用内存，蓝色曲线代表每次垃圾回收后可用的内存。已使用内存逐渐增加，可用内存的持续降低表明系统可能存在内存泄漏。

4. TPV监视JVM的状况

另外一种方法是借助TPV和PMI来实时监视JVM，分析性能曲线来判断是否有内存泄漏的状况发生。 WebSphere性能监控基础结构(PMI)和Java虚拟机概要分析工具接口（JVMTI）可以帮助我们收集系统的性能状况数据，使用Tivoli性能查看器(TPV)以图形的方式显示这些数据（性能计数器），可以进一步证实是否系统正在发生内存泄漏。

4.1 PMI与TPV

PMI 提供WebSphere运行时和应用程序资源行为的一组全面的数据,。例如，PMI 提供数据库连接池大小、servlet 响应时间、 Enterprise JavaBeans（EJB）方法响应时间、Java 虚拟机（JVM）垃圾回收时间以及 CPU 使用量等等。使用 PMI 数据，可以识别并修正应用程序服务器中的性能瓶颈, 还可使用 PMI 数据来监控应用程序服务器的运行状况。PMI 数据可以由 Tivoli Performance Viewer（TPV）、其他 Tivoli 工具、您自己的应用程序或第三方工具来监控和分析。TPV 是随 WebSphere Application Server 一起提供的 PMI 数据图形查看器。

Tivoli Performance Viewer（TPV）使得我们可以通过查看图表或表格，从而解读WebSphere的性能监控基础结构（PMI）数据。

4.2 PMI的配置方法

默认情况下，PMI已经开启，级别是默认(Default)。配置步骤：

1. 在控制台导航树中单击监视＆调整-> 性能监视基础结构(PMI)。

2. 选择所要配置的服务器名字。

3．单击配置选项卡，这里可以根据监控内容的需要，来选择PMI的任一种统计信息集（无，基本，扩展，全部，定制）。我们这里选择"定制"。

注：如果在配置选项卡中，则当重新启动服务器时应用设置。如果在运行时选项卡中，则立即应用设置。

4．点击定制 -> 在定制监视级别的树中，选择配置选项卡，然后点开JVM运行时，可以根据需要，启用或禁用相应的计数器。

5．保存并重启WebSphere服务器。

4.3 TPV的使用方法

实时查看 TPV 性能模块的步骤：

（1） 在控制台导航树中，单击监控和调整 -> 性能查看器 -> 当前活动 -> 服务器名字）-> 性能模块。

（2） 选中要查看的每个性能模块，例如JVM运行时。

（3） 单击查看模块按钮。 在页面的右侧会显示所选性能数据的图形或切换成表格。注：每个模块有与其关联的多个计数器。这些计数器会显示在数据图形或表格下面的表中。您可以通过选择或取消选择计数器旁的复选框，将计数器添加到图表或表中，或从中除去。

TPV显示的已使用内存的图形理想情况下应该是锯齿状，图形中每个坡（下降）对应着一次内存的垃圾回收(Garbage collection)，如下图已使用内存的曲线，显示的是没有发生内存泄漏的状况。

如果测试过程中出现如下情况，则有可能发生了内存泄漏：

－每次垃圾回收后的已使用内存的数值骤增。

－TPV对应的已使用内存图形更接近于阶梯（staircase），或者锯齿形状严重不规则。

－也可以查看分配的对象数与释放的对象数之差值，如果这个数值越来越大，则有内存泄漏（如果需要查看对象数，需要启用JVMTI接口并在PMI中启用相应的JVM计数器）。

上图，红色曲线代表已使用的内存，从整体趋势，我们可以看出已使用内存一直在增长。 TPV可以帮助发现内存泄漏，为了得到最优结果，我们可以重复试验，而且每次可以增加测试的时间，例如测试1000，3000或5000个页面请求。

5. 生成Heap dump文件

WAS6.1中，在使用IBM JDK的平台上，可以直接使用以下的方法，随时生成所需的heapdump文件。如果在性能诊断顾问程序配置里面选中了"启用自动堆转储收集，则可以自动在WebSphere profile所在的路径下（例如/opt/IBM/WebSphere/WAS6.1/profiles/AppSrv01）生成heapdump文件，备用户进行分析。

在使用IBM SDK的平台上，例如AIX, Linux和Windows，在启用了性能诊断顾问工具后，如果探测到有内存泄漏发生，WebSphere会自动生成两个heapdump文件，供后续分析使用。

我们在任何时候，可以随时手动生成所需的heap dump文件。在WAS6.1 profile的bin目录下，首先运行wsadmin 脚本客户端，然后可以调用generateHeapDump操作来完成。

关键步骤：

1． 找到JVM对象名字。

set objectName
WebSphere:type=JVM,process=,node=<节点名字>,*]
2． 对JVM MBean调用generateHeapDump操作。

$AdminControl invoke $objectName generateHeapDump
例如：

[root@csspvm bin]# pwd
/opt/IBM/WebSphere/WAS6.1/profiles/AppSrv01/bin
[root@csspvm bin]# ./wsadmin.sh -username root -password demo4you
WASX7209I: Connected to process "server1" on node csspvmNode02 using SOAP
connector;  The type of process is: UnManagedProcess
WASX8011W: AdminTask object is not available.
WASX7029I: For help, enter: "$Help help"
wsadmin>set objectName [$AdminControl queryNames
WebSphere:type=JVM,process=server1, node=csspvmNode02,*]
WebSphere:name=JVM,process=server1,platform=proxy,node=csspvmNode02,
j2eeType=JVM,J2EEServer=server1,
version=6.1.0.0,type=JVM,mbeanIdentifier=JVM,cell=csspvmNode02Cell,spec=1.0
wsadmin>$AdminControl invoke $ objectName generateHeapDump
/opt/IBM/WebSphere/WAS6.1/profiles/AppSrv01/./heapdump.20060904.075650.3576.phd
wsadmin>quit
 

理想情况下，在探测到问题时，尽快生成一个初始的heap dump，然后密切监控内存使用情况，等到泄漏了足够的内存的时候，再生成另外一个heap dump，这样可以对比分析以更准确地找到泄漏的原因。

注： 生成HeapDump文件的过程是比较耗资源的，所以请只在必须的时候做这样的操作。

6内存泄漏的分析诊断工具－MDD4J

一旦确定了系统中有内存泄漏，并且为此生成了heap dump。接下来，我们可以把这些文件从WebSphere应用服务器转移到离线的分析工具所在的机器，进行离线分析诊断。

6.1 工具介绍

MDD4J（Memory Dump Diagnostic for Java）是一个内存泄漏分析工具，用于对运行 WebSphere Application Server 的虚拟机（JVM）所生成的常用内存转储（堆转储）格式进行分析。进行内存转储（Memory dump）分析的目的，是为了确定 Java 堆中真正导致内存泄漏的类和包(classes and packages)，这样可以缩小内存泄漏的范围并找到真正的原因，此分析还确定应用程序 Java 堆占用量的主要组成部分以及它们之间的拥有关系。

此工具支持下列格式的内存转储格式有：

－IBM 的PHD格式（heapdump.phd）

－IBM 文本堆转储（heapdump.txt）

－HPROF 堆转储格式（hprof.txt，主要针对Solaris和HP-UX平台）

－SVC 转储（dump.bin，IBM z-Series上的WebSphere）

该工具提供了两种分析机制：单转储分析以及对两个转储进行的比较分析。

单转储分析最常用于在发生 OutOfMemoryException 时自动触发的内存转储。此类分析查找可疑的数据结构，能够相对快速地提供可疑泄漏对象的分析结果。

比较分析用于对运行内存泄漏应用程序期间（即可用 Java 堆内存流失时）获取的两个内存转储进行分析。在运行泄漏应用程序的早期触发的内存转储被称为基线内存转储，发生泄漏的应用程序运行一段时间（以允许泄漏程度加大）后触发的内存转储被称为主内存转储。在发生了内存泄漏的情况下，主内存转储可能包含大量对象，而这些对象占用的 Java 堆空间量会比基线内存转储大很多。

为了获得更好的分析结果，建议使主内存转储的触发点与基线内存转储的触发点在时间上拉开一定距离，从而使总耗用堆大小在两个触发点之间大幅增长。

MDD4J的分析结果显示是基于WEB界面的，具有下列特征：

- 列示分析结果、堆内容、大小和增长幅度的总结

- 列示可疑的数据结构、数据类型和包，它们是造成堆使用量增加（对于比较分析）和堆大小较大（对于单转储分析）的主要原因。

- 拥有关系上下文视图显示了占用量主要组成部分之间的关系，以及一组汇总的主要占用量组成部分所包含的重要数据类型。

- 在堆转储内容的交互式树形视图中，浏览功能能够显示堆中任何对象的所有进入引用（在树中只显示一个引用，其余引用单独显示）和外出引用，而子对象按到达大小排序。

- 导航功能使您能够从可疑对象列表转到所有关系上下文，以及从内容视图转到浏览视图。

- 提供了内存转储中所有对象和数据类型的表视图，视图中具有过滤器和经过排序的列。

6.2工具的使用

WebSphere 应用服务器v6.1的附带光盘里面有IBM Support Assistant工具的安装文件，运行相应的安装文件，MDD4J作为插件同时被安装了。

另外，也可以从IBM 技术支持站点http://www-306.ibm.com/software/support/isa/ 下载Support Assistant工具，然后选择更新程序，独立安装MDD4J插件。

启动步骤：

(1) 程序->IBM Support Assitant ->IBM Support Assistant v3

(2) 在Support Assistant窗口中，选择工具 -> 选择WebSphere版本号。

点击MDD4J的链接，就可以开启MDD4J工具。在该界面中，我们可以提交单个heap dump文件进行单转储分析，或同时提交两个文件进行比较分析。也可以从内存转储分析结果的下拉选项中选择以前的分析结果，从而查看以前的分析内容。

查看分析进度

单击"上载并分析"按钮后，MDD4J开始分析heap dump文件。在分析执行过程中，登录页面将自动刷新，以反映当前正在执行的分析步骤以及整体分析进度。如果该页面由于某种原因而不刷新，您可以单击"刷新"按钮以了解当前分析状态。如果您希望停止分析，可以单击"停止"按钮，这将在当前正在执行的模块完成后终止分析。

在提交了heap dump文件，MDD4J显示分析状态。

查看分析结果

分析完成后，Mdd4J页面将重定向到"分析结果"页面。"分析结果"页面包含 4 个选项卡：

"分析总结"选项卡：显示分析结果总结，并列示下一组用于查看分析结果的步骤。

"可疑对象"选项卡：它显示四类可疑对象，即对增长幅度影响最大的数据结构、到达大小显著流失的数据结构、有大量实例的对象类型以及有大量对象实例的 Java 包。

"察看上下文和内容"选项卡：显示主内存转储中 Java 堆占用量的主要组成部分的拥有关系上下文图，以及图中所选节点的内容。

"浏览"选项卡：根据对对象引用图执行的深度优先遍历，用树形视图显示主内存转储的所有内容。

其他内容，请参照MDD4J工具附带的Help文档，该帮助文档有详细的使用说明，在此不再赘述。

7．小结

IBM提供了一系列的工具辅助用户进行内存问题的监控和分析，在合适的阶段选择合理的工具可以帮助我们轻松搞定内存泄漏。这里介绍的工具都是WebSphere附带或者免费的，IBM Tivoli工具还提供了更强大的监控和诊断功能，例如ITCAM (IBM Tivoli Composite Application Management)，可以根据实际情况选用。

TPC-C

作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。

相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。

TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。

TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。

tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。

1．TPC-C规范概要

TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。

TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。

该系统需要处理的交易为以下几种：

•   New-Order：客户输入一笔新的订货交易；

•   Payment:更新客户账户余额以反映其支付状况;

•   Delivery:发货(模拟批处理交易);

•   Order-Status:查询客户最近交易的状态；

•   Stock-Level:查询仓库库存状况，以便能够及时补货。

对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。

逻辑结构图：

流程图：

2．评测指标

TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。

TPC-C的测试结果主要有两个指标：

● 流量指标(Throughput，简称tpmC)

按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。

流量指标值越大越好！

● 性价比(Price/Performance，简称Price/tpmC)

即测试系统价格（指在美国的报价）与流量指标的比值。

性价比越小越好！

3．结果发布

各厂商的TPC-C测试结果都按TPC组织规定的两种形式发布：测试结果概要(Executive Summary)和详细测试报告(Full Disclosure Report)。测试结果概要中描述了主要的测试指标、测试环境示意图以及完整的系统配置与报价，而详细测试报告中除了包含上述内容外，还详细说明了整个测试环境的设置与测试过程。

P690 tpmC测试值：76,389,839.00

$/tpmC：831.00

美国美金报价：6,349,223.0

CPU数：32

数据库：IBM DB2 UDB 8.1

操作系统：AIX 5L V5.2

中间件：TUXEDO 8.0

测试日期：2003.6.30

P690 TPC-C测试的配置：

1．  后台：1 x eServer pSeries 690 with 32 x 1.7GHz POWER4+ processors with 128MB L3 cache per MCM (total of four MCMs), 512GB memory

2．  前端：30 x eServer pSeries 630 Model 6E4 each with 4 x 1.0GHz POWER4 CPUs with 32MB L3 cache, 16GB memory

SPECweb:

SPECweb96: 在SPECweb96基准测试程序上实现的每秒钟超文本传输协议（HTTP）操作最多次数，响应时间无明显退化。

SPECweb99: 接入数，网络服务器可用预先确定的工作量支持的同时接入数。SPECweb99检测设备模拟客户通过慢Internet联接，向网络服务器发送HTTP工作量请求。

SPECweb99 测试Web服务器运行状况

SPECweb99 是由标准性能评估组织（SPEC）开发的Web服务器基准测试。它测量满足特定吞吐量和客户请求响应速率要求的WEB服务器的最大并发连接数量。并发连接的合计波特率在320 Kbps到400Kbps范围内，则满足相应规范。

SPECweb99 在一台称为主客户端的机器上运行，这台机器上包含有允许用户加载特定负载请求的配置文件。主客户端也要处理在客户端和服务器或测试中的系统（SUT）之间的传输协调问题。客户端通过许多子进程／线程生成独立HTTP请求流，仿真足够的负载发送给SUT。图二表示客户端／服务器的层次关系。

图：典型的SPECweb99实验环境

在这个测试中，客户端向测试中的服务器发送请求数据。测试规范要求客户端和服务器之间的连接不能使用片段大小大于1460比特的TCP协议。因此，每一个客户端读取1460比特或更少数据块的响应。

测试中使用两种类型的负载量：

静态负载. 静态负载具有四种类型的文件。最小的文件的增幅为0.1KB，第二种文件类型的增幅为1KB，最后两种类型的文件的增幅为10KB和100KB。每一个目录包含每种类型9个文件共36个文件。

目标请求的文件类型在各类型中分散使用。在每一类中的9个文件中又进行二次分布。最终目标文件混合为：

35％的请求文件小于1 KB

50％的请求文件小于10 KB

14％的请求文件小于100 KB，但是大于或等于10 KB

1％的请求文件小于1000 KB，但是大于或等于100 KB

动态负载.动态负载是基于广告和用户注册。共有四种在SPECweb99中使用的请求内容类型，分别是标准动态取操作、动态随机取操作、动态发送操作和客户图形接口动态取操作。标准动态取操作和客户图形接口动态取操作表现web服务器的简单广告轮转特性。带有广告轮转的动态取操作追踪用户和用户选择，所以广告可以由不同的方式来定制。最终，动态发布实施一个用户注册在相应的网站上。

P690 SPECweb99测试值：21,000

Web服务器：Zeus 4.0

操作系统：AIX 5L V5.1 (64-bit)

CPU数：16

测试日期：2001-10-1

测试配置：16 x 1.3GHz POWER-4 Processors w/1440KB unified on chip L2 cache, 192GB memory, 32 x 32 IBM Gigabit Ethernet-SX PCI controllers, 32 x Gigabit Ethernet network (1 Gigabit/sec  ), 96 x Clients (4 x 375MHz POWER3-II, RS/6000 44P-270), Requested Connections = 21000, Max Fileset Size = 67319.6MB

P650 SPECweb99测试值：12,400

Web服务器：Zeus 4.1r3

操作系统：AIX 5L V5.2 (64-bit)

CPU数：8

测试日期：2002-10-1

测试配置：8 x 1.45GHz POWER4+ processors w/1.5MB(I+D) unified on chip L2 cache, 32MB unified off chip/SCM L3 cache, 64GB memory, 8 x Gigabit Ethernet-SX PCI-X controllers, 8 x Gigabit Ethernet network (1 Gigabit/sec ), 48 x Clients (6 x 668MHz RS64-IV, pSeries 620 Model 6F1), Requested Connections = 12400, Max Fileset Size = 39801.28MB

p630 SPECweb99测试值：6,895

Web服务器：Zeus 4.2r1

操作系统：AIX 5L V5.2(64-bit)

CPU数：4

测试日期：2003-2-1

测试配置：4 x 1450MHz POWER4+ Processors w/1536KB(I+D) unified on chip L2 cache, 8MB unified (off chip)/SCM L3 cache, 32GB memory, 4 x Gigabit Ethernet-SX PCI-X controllers, 4 x Gigabit Ethernet networks (1 Gigabit/sec ), 24 x Clients (4 x 375MHz POWER3-II, pSeries 640 Model B80), Requested Connections = 6900, Max Fileset Size = 22199.12MB

NotesBench:

NotesBench是测试各种不同Lotus Notes方面的驱动程序。目的是执行自定义工作量教本中的命令，模拟客户机的操作。NotesBench测试“仅测试邮件”和“测试邮件和数据库”。所有已经公布的IBM结果均为“仅测试邮件工作量”。

p680 NotesBench测试值：150,197

用户数：108,000

平均反应时间：0.584秒

Domino服务器版本：5.06a

操作系统：AIX 4.3.3

CPU数：4

测试日期：2001.11.20

测试配置：IBM eServer pSeries 680 (24*RS64 IV/600MHz; 96GB RAM, 30 Partitions)