Sysstat介绍

        Linux中的top,free等命令不能完全满足我们性能数据收集的要求，我们需要一个更加强大的工具来收集性能数据。经过考察和对比，发现Sysstat是一个非常强大的工具，因此下载了试了下，效果不错。Sysstat是一个工具集，包括sar、pidstat、iostat、mpstat、sadf、sadc。其中sar是其中最强大，也是最能符合我们测试要求的工具，同时pidstat也是非常有用的东东，因此本文结合性能测试重点介绍这两个工具。

Sysstat的安装

        从http://pagesperso-orange.fr/sebastien.godard/download.html下载最新版本，解压，安装

•  wget http://pagesperso-orange.fr/sebastien.godard/sysstat-8.1.2.tar.gz
   tar zxvf sysstat-8.1.2.tar.gz
   cd sysstat-8.1.2
   ./configure
   make
   su
   <enter root password>
   make install

监视某个进程

1.      通过ps命令找到相应进程的PID：

ps -e

2.      使用pidstat命令监视进程，详细用法见：http://pagesperso-orange.fr/sebastien.godard/man_pidstat.html

pidstat 2 5 
//每隔2秒，显示5次，所有活动进程的CPU使用情况
pidstat -p 3132 2 5 
//每隔2秒，显示5次，PID为1643的进程的CPU使用情况显示
pidstat -p 3132 2 5 -r
//每隔2秒，显示5次，PID为1643的进程的内存使用情况显示

3.      很可惜的是，pidstat命令没有保存性能数据的功能。

查看性能数据

        在sysstat工具包中，sar是最强大的了，通过sar几乎可以监视所有的性能数据，同时，sar还支持将性能数据保存起来。
sar详细用法请见：http://pagesperso-orange.fr/sebastien.godard/man_sar.html

1.      查看CPU使用情况

sar 2 5
//每隔2秒，显示5次，CPU使用的情况

2.      查看内存使用情况

sar -r 2 5
//每隔2秒，显示5次，内存使用的情况

3.      查看网络吞吐量

sar -n DEV 2 5
//每隔2秒，显示5次，网络吞吐量情况

保存性能数据

        sar支持保存成两种格式的文件，一种是文本文件，一种是二进制文件（只有通过sar自己的命令才能查看）。

1.      保存为文本文件

结合上面的查看命令，加入 > filename 参数即可保存文本文件，下面列出几个有用的命令：

sar 1 10 > data.txt
//每隔1秒，写入10次，把CPU使用数据保存到data.txt文件中。
sar 1 0 -e 15:00:00 > data.txt
//每隔1秒记录CPU的使用情况，直到15点，数据将保存到data.txt文件中。(-e 参数表示结束时间，注意时间格式：必须为hh:mm:ss格式)
sar 1 0 -r -e 15:00:00 > data.txt
//每隔1秒记录内存使用情况，直到15点，数据将保存到data.txt文件中。
sar 1 0 -n DEV -e 15:00:00 > data.txt
//每隔1秒记录网络使用情况，直到15点，数据将保存到data.txt文件中。

用WinSCP工具从Linux服务器上取下data.txt文件，内容如下：

Linux 2.6.18-53.el5 (Performancesvr5)  2008年05月05日     _x86_64_

 11时04分05秒     CPU     %user     %nice   %system   %iowait    %steal     %idle
 11时04分06秒     all      0.25      0.00      0.00      0.00      0.00     99.75
 11时04分07秒     all      0.00      0.00      0.25      0.00      0.00     99.75
 11时04分08秒     all      0.25      0.00      0.25      1.50      0.00     98.00
 11时04分09秒     all      0.25      0.00      0.00      0.50      0.00     99.25
 11时04分10秒     all      0.00      0.00      0.00      0.00      0.00    100.00
 11时04分11秒     all      0.25      0.00      0.25      0.00      0.00     99.50
 11时04分12秒     all      0.00      0.00      0.25      0.00      0.00     99.75
 11时04分13秒     all      0.50      0.00      0.50      0.99      0.00     98.01
 11时04分14秒     all      0.00      0.00      0.00      1.25      0.00     98.75
 11时04分15秒     all      0.50      0.00      0.00      0.00      0.00     99.50
 平均时间:     all      0.20      0.00      0.15      0.42      0.00     99.23

有了这份数据，就可以轻松的使用WPS表格来统计CPU的使用情况了。

保存为二进制文件

        由于保存的二进制文件只有sar通过-f参数才能打开，不利于我们分析和统计数据，因此不推荐使用这个方法。保存二进制文件的参数是-o，如：

sar 1 5 -r -o data
//每隔1秒，写入5次，将内存使用的数据写入二进制文件data中。
sar -f data
//查看data文件

目的

本工具向导说明了如何在 Rational Robot^TM 中设置测试环境。

相关的 Rational Unified Process 活动：

• 活动：实施测试中的“记录或通过编程创建测试脚本”部分
• 活动：执行测试中的“执行测试过程和/或测试脚本”部分

概述

本工具向导适用于 Microsoft Windows 95/98/NT 4.0。

要使用 Robot 来设置测试环境，请执行以下步骤：

1. 设置测试环境以进行记录、编辑或测试脚本回放。
2. 设置 GUI 脚本记录选项。
3. 设置 GUI 脚本回放选项。

1. 设置测试环境以进行记录、编辑或测试脚本回放

Windows 环境和您所测试的应用程序的状态会影响脚本的回放。如果所记录的环境和回放环境之间存在差异，回放就会出现问题。

在记录或编辑测试脚本之前，确保您所测试的应用程序和所有其他软件（在测试环境中）都处于适当的初始状态。另外，在执行测试（回放测试脚本）之前，请保证所测试的应用程序和所有其他软件都处于记录/编辑该测试脚本时所处的初始状态。当您开始回放脚本时，记录脚本时处于打开、激活或显示状态的所有应用程序和窗口应该仍处于打开、激活或显示状态。此外，确保所有相关的网络设置、现用数据库和系统内存处于同记录脚本时相同的状态。

回放测试脚本时，确保您设置了适当的回放选项，其中包括 Robot 应该如何处理意外活动窗口以及如何从脚本命令错误中恢复（请参见下一部分）。

2. 设置 GUI 脚本记录选项

GUI 脚本记录选项指示 Robot 在记录测试脚本时，应如何处理某些对象、鼠标拖动、窗口设置、对象内容和 Robot 窗口。

要设置 GUI 脚本记录选项，请执行以下步骤：

1. 执行以下操作之一来显示 GUI Record Options 对话框：

• 开始记录之前，请单击 Tools > GUI Record Options。
• 单击工具栏上的 Record Script 按钮，开始记录。在 Record 对话框中，单击 Options。

2. 设置每个选项卡上的选项。有关各选项卡的详细信息，请参见 Using Rational Robot 手册中的 Setting GUI Record Options 一章或参见 Robot 联机帮助。

General - 指定 Robot 如何确定/识别列表和菜单内容，以及不支持的鼠标拖动。另外，在此选项卡中，您还可以指定：用于脚本自动命名的前缀、是否让 Robot 来保存和恢复活动窗口的大小和位置、是否记录思考时间、是否记录按下回车键后的延迟。Robot Window - 指定记录测试脚本时 Robot 窗口的显示方式。该选项卡还使用户可以指定热键，用来隐藏/重新显示 Robot 窗口，以及在面向对象的记录模式和低层记录模式之间进行切换。Object Recognition Order - 用于在记录之前或记录过程中，改变个别对象类型的对象识别方法优先级。

有关如何记录脚本的详细信息，请参见工具向导：使用 Rational Robot™ 创建测试脚本。

3. 设置 GUI 脚本回放选项

GUI 脚本回放选项指示 Robot 如何回放 GUI 脚本。您既可以在回放之前，也可以在回放过程开始时设置这些选项。

要设置 GUI 回放选项，请执行以下步骤：

1. 执行以下操作之一来显示 GUI Playback Options 对话框：

• 开始回放之前，请单击 Tools > GUI Playback Options。
• 单击工具栏上的 Playback Script 按钮，开始回放。在 Playback 对话框中，单击 Options。

2. 设置每个选项卡上的选项。有关各选项卡的详细信息，请参见 Using Rational Robot 手册中的 Setting GUI Playback Options 一章或参见 Robot 联机帮助。

   Playback - 指定命令和击键之间的延迟、是否使用记录的思考时间和键入延迟、是否跳过核实点、是否显示确认结果对话框，以及回放过程中 Robot 窗口中出现的内容。有关详细信息，请单击对话框中的 Help 按钮。Log - 指定日志中保存的结果、回放后是否显示日志、是否要在覆盖日志之前得到提示、以及是使用默认日志信息还是使用您提供的信息。

   Caption Matching - 指定 Robot 如何匹配记录过程中所记录的窗口标题和回放过程中发现的标题。有关详细信息，请单击对话框中的 Help 按钮。

   Wait State

   - 指定回放时的默认重试和超时值。

   Unexpected Active Windows

   - 指定 Robot 应该如何响应意外的活动窗口。

   Error Recovery

   - 指定在脚本回放时，Robot 如何从脚本命令错误和核实点故障中恢复。

   Trap

   - 指定 Trap 实用程序应该记录的有关回放过程中常见保护故障的信息和恢复方法。
3. 单击 OK。

   有关如何回放脚本的详细信息，请参见工具向导：使用 Rational Robot™ 执行测试。

　　验证测试是用于验证在特定的场景、时间、压力、环境和操作方式下系统能够正常的运行，服务器、应用系统和网络环境等软硬件设施还能否良好的支撑这些情况下用户的使用。验证性测试主要针对有明确的压力目标和预期结果，验证系统在这种压力下的各方面反映能够达到预期结果。

　　主要分以下几种：

　　压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。

　　Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。

　　Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。

　　另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。

 　　稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

　　根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。

　　场景设计思想：从稳定性测试场景的设计意义，应分多种情况考虑：

　　针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：

　　1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。

　　2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

　　测试方法：采用1)Ramp Up-Load all Vusers simultaneously

　　2)Duration-Run Indefinitely

　　3)在Sechedule-勾选Initalize all Vusers before Run

 　　容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

 　　问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

　　测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）。

 　　评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。

 　　评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。

 　　评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。

 　　评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。

　　问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。

　　该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

　　验证测试是用于验证在特定的场景、时间、压力、环境和操作方式下系统能够正常的运行，服务器、应用系统和网络环境等软硬件设施还能否良好的支撑这些情况下用户的使用。验证性测试主要针对有明确的压力目标和预期结果，验证系统在这种压力下的各方面反映能够达到预期结果。

　　主要分以下几种：

　　压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。

　　Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。

　　Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。

　　另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。

 　　稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

　　根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。

　　场景设计思想：从稳定性测试场景的设计意义，应分多种情况考虑：

　　针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：

　　1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。

　　2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

　　测试方法：采用1)Ramp Up-Load all Vusers simultaneously

　　2)Duration-Run Indefinitely

　　3)在Sechedule-勾选Initalize all Vusers before Run

 　　容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

 　　问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

　　测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）。

 　　评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。

 　　评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。

 　　评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。

 　　评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。

　　问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。

　　该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

分析原则：

• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

• 查找瓶颈时按以下顺序，由易到难。

    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

• 分段排除法 很有效

分析的信息来源：

•1 根据场景运行过程中的错误提示信息

•2 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：

1 •Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection

•Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely

分析：

•A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题）

•B、应用服务没有死

（应用服务参数设置问题）

    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

•C、数据库的连接

(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2 Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成

•A、应用服务参数设置太大导致服务器的瓶颈

•B、页面中图片太多

•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析

1．最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

    在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

    如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：

    • 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3．服务器资源监控指标：

内存：

1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate);

进程进入不活动状态;

交换区所有磁盘的活动次数可高;

可高的全局系统CPU利用率; 

内存不够出错(out of memory errors)

处理器：

1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 

合理使用的范围在60%至70%。

2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆: 

很慢的响应时间(slow response time) 

CPU空闲时间为零(zero percent idle CPU) 

过高的用户占用CPU时间(high percent user CPU) 

过高的系统占用CPU时间(high percent system CPU) 

长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：

1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :

过高的磁盘利用率(high disk utilization) 

太长的磁盘等待队列(large disk queue length) 

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 

太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：

SQL Server数据库：

1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。

2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 

3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率： 

select(sum(pins-reloads))/sum(pins) from v$librarycache; 

select(sum(gets-getmisses))/sum(gets) from v$rowcache; 

自由内存： select * from v$sgastat where name=’free memory’; 

2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：

select name,value from v$sysstat where name in (’db block gets’,

‘consistent gets’,'physical reads’) ;

Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况 ：

select name,value from v$sysstat where name = ‘redo log space requests’ ;

4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

内存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’

注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

本文出自51testing博客，转载请注明出处
原始链接： http://blog.51testing.com/?49159/action_viewspace_itemid_869.html

【摘要】 在大型软件系统投入生产之前进行性能测试已经成为趋势，本文结合一个性能测试案例对性能测试的过程和原理进行了介绍。

【关键字】 性能测试　　并发测试　　负载测试

•  软件测试中的性能测试

软件测试是保证软件质量的重要手段，也是软件过程中一个必不可少的环节。而性能测试则隶属于软件测试中的系统级测试，它对软件在集成系统中运行的性能行为进行测试，旨在及早确定和消除软件中与构架有关的性能瓶颈。

•  性能测试的含义

目前对性能测试没有明确的定义，一般地，它主要是针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方面的能力，如系统并发处理能力，批量业务处理能力等。

•  性能测试的分解

在性能测试的执行中，可以根据具体的性能指标，分解为几种测试，根据其关系，可以在不同的时间和空间内执行。这些子测试通常包括以下几种：

并发测试：验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。

负载测试：验证系统的负载工作能力。系统配置不变的条件下，在一定时间内，服务器端在高负载情况下的性能行为表现。这里的负载可以是用户数，交易数，事务数等。

配置测试：核实在操作条件保持不变的情况下，系统在使用不同配置时其性能行为的可接受性。

健壮性测试：核实被测系统的性能行为在异常或极端条件之下的可接受性。这里的异常或极端条件指的是资源过少，用户数过多，突发故障等。

随着软件系统的规模日益庞大，结构日趋复杂，对软件系统的性能测试已经成为必须和趋势。尤其大型的分布式软件系统更要在正式运行前进行性能测试，因为这样的系统在投入生产之后，往往要接受大批量的业务量，这对应用程序本身，操作系统, 中心数据库服务器，中间件服务器，网络设备的承受力都是一个严峻的考验。在其中任意一个环节出现的问题都可能给用户带来巨大的商业损失。预见软件系统的并发承受能力以避免商业风险，这是在软件测试阶段就应该解决的。例如中国人民银行的现代化支付系统和上海外汇交易中心的本币交易系统都在投入生产之前进行了多轮的第三方性能测试，起到了很好的作用。

下面我就介绍一个性能测试案例。

• 一个性能测试实例

• 被测系统

1)被测系统介绍

本系统应我国金融信息化发展设计，采用当今比较先进和流行的技术，是运行在城域网上的大型分布式应用系统。

本系统遵循J2EE规范，采用B/S体系结构进行设计和开发。业务主要分为交易业务和查询业务，查询业务采用J2EE规范，交易业务以J2EE体系架构为基础，进行进一步的处理，采用了TCP的四层结构。系统体系结构图如下：

图表 1被测系统体系结构设计图

• 表示层：　

运行在终端上。运行java applet程序，提供协议控制和用户界面，与系统最终用户实现直接交互，通过TCP/HTTP与前置系统通讯。向前置系统发送请求报文，并接收前置系统返回的回应报文。

• 商业逻辑层：

作为中间层实现核心业务逻辑服务。

交易应用服务：运行在交易主机上。在tuxedo中间件上运行业务处理程序，按交易规则处理前置机发来的交易指令，通过tuxedo jolt与前置机连接，通过DB2 C API与数据库连接。

交易前置服务和查询前置服务：运行在前置机上。交易前置服务运行服务程序接收终端请求报文并通过tuxedo jolt客户端将其转发给交易主机，再通过轮询和同步反馈接收交易主机返回的报文，将其转发给业务终端；查询前置服务运行在weblogic应用服务器上并调用Jreport组件，通过JDBC完成对查询流指令的发送并接受数据库返回的结果给业务终端。

• 数据层：

运行在数据库主机上。负责整个系统中数据信息的存储、访问及其优化。运行DB2数据库服务程序。通过DB2 C API与交易主机通讯，JDBC与查询前置服务通讯。

2) 被测系统的性能要求和性能指标

金融系统是业务处理十分频繁、数据交换吞吐量很大的系统，业务处理的速度直接关系到公司的经济效益和客户对公司的评价。在客观条件下，整个广域网系统必须在大业务量的情况下同时保持快速的实时响应能力，以保证整个业务系统的通畅运行。用户对此提出如下性能指标：

表格1用户要求性能指标表

下面我们会根据此系统和给定的性能指标来进行性能测试：

•  对被测系统进行性能测试

性能测试的目的是最大程度地模拟真实业务场景，来验证系统的性能指标，并发现可能存在的性能瓶颈。

1)对被测系统进行系统分析

我们可以看到本系统大体上由终端、前置机、交易主机、数据库主机节点组成。

在整个业务流程中，业务终端→前置机→交易主机→数据库主机形成了一个压力流串，每个节点在压力下能够正常工作是整个系统正常运转的基础。也就是说，如果其中任意一个节点在业务压力下发生了拥塞、处理不力等不正常情况，那整个系统都无法正常运转。

我们来看一下业务流程。

首先，从终端到前置机，终端产生业务报文发送至前置机，前置机上运行查询前置服务和交易前置服务，查询前置服务向下通过HTTP协议以WEB服务形式和终端连接，向上通过JDBC直接与数据库系统相连。交易前置服务向下通过基于TCP协议的socket连接和终端通讯，向上通过tuxedo jolt客户端和交易应用服务连接。交易应用服务进行业务逻辑计算，并操作数据库系统。

由以上分析，我们可以整理出整个系统的两条压力流程线来，之所以我们把其分为两条流程线，是因为交易前置服务和查询前置服务的工作原理完全不同，下与终端的连接，上与交易主机的连接也完全是独立的两个通路。

终端→交易前置机→交易主机→数据库系统

终端→查询前置机→数据库系统

下面我们先独立分析两条流程线，之后我们将再次综合分析，以考虑二者之间的相互影响作用。

第一条路线上主要运行的是登陆指令和交易指令信息。

当系统运作时，多个交易终端与交易前置服务建立socket连接，完成登陆，之后发送交易指令，造成对交易前置服务的压力。交易前置服务通过运行服务程序接收到交易指令，并检验其合法性，然后通过交易中间件tuxedo的客户端把业务的压力传递给交易主机进行处理。交易主机进行必要的金融计算和业务逻辑运行，得出反馈结果，生成消息，一方面顺原路返回到各个终端上去，一方面记录入数据库。

在本条流程线上的加压主要考验交易前置服务程序的socket多连接建立能力，tuxedo交易中间件的即时响应能力，交易主机的计算能力，以及DB2数据库的DML语句加锁机制。

第二条路线上主要运行的是查询指令信息。

查询指令产生时，通过http协议访问weblogic上的web服务器和应用服务器上的相应组件，以JDBC接口访问后台的DB2数据库，并把数据库返回的结果发送至终端界面。

在本条流程线上的加压主要验证weblogic处理能力，数据库中索引是否创建合理。

两条流程线相对独立，但又是互相依赖的。由于是对同一个数据库系统进行读操作和写操作，查询流程的结果依赖于交易流程数据的产生，交易流程的产生的数据又通过查询流程得到验证。在进行压力测试时，两者的协同会对数据库形成压力的冲击。

A: 并发登陆测试：750个终端一分钟内并发登陆系统，并且响应时间在30秒之内。

B: 业务负载测试

此下又有三个子测试。

• 交易流程测试：多个终端发起交易请求，逐渐加压，以达到300笔/秒的压力为限。

• 查询流程测试：多个终端进行查询，逐渐加压，以达到400笔/秒的压力为限。查询成功与否以所请求的web页面完全展现为标准。（查询响应能力其实和数据库中的数据量有关系，后来和用户进一步确认，基础数据为30万条）

• 综合测试：

在上面两种测试都通过的情况下，进行综合测试。

2)性能测试的执行过程，性能测试依照下面的步骤来进行：

• 第一步：测试脚本的开发

本次压力测试采用MI公司的loadrunner工具，脚本编辑和编译工作在VU Generator(脚本作坊)中进行。

理想的脚本是对现实世界的业务行为进行了完全无误的模拟，这其实是不可能的。我们的目标是使模拟的误差在我们认可的范围之内，并能有方法加以控制。

针对并发登陆测试和交易流程测试，由于两者运行机理相同，都是终端调用socket client，和交易前置的socket server建立连接，将请求消息发送至交易前置机。我们考虑采用将此部分java socket程序编入测试脚本程序，生成登陆和交易业务脚本，通过loadrunner来执行。这样做的好处是绕过终端IE界面复杂的处理逻辑，直接施压在前置机上（这种方式同时也带来了偏差，在执行测试场景时通过其它方法得到了一定的弥补）。

脚本除了要实现与前置机的socket连接，业务发送等功能，还要建立用户信息数据池，设置检测点、异常退出点，为脚本执行后的结果统计和分析提供正确的依据。

交易业务脚本内容略。部分如下：

………………………….

………………………….

………………………….

………………………….

…………………………

…………………………

…………………………..

在上面的例子中，我们主要对每笔交易进行了transaction化。在交易开始时设置开始检测点，交易结束时设置结束检测点，并给loadrunner报出交易状态。实际的脚本中在回收交易响应消息时还进行了拆包，在应用层上对交易状态进行识别，并非例子中只在socket层加以判断。

针对查询流程测试，由于loadrunner工具支持基于http的web访问录制功能，我们将考虑采用以录制脚本为主，手工编写脚本为辅的方法，生成查询业务脚本，通过loadrunner来执行。由于查询脚本基本由录制生成http请求和应答，不同的压力测试工具录制会有差别，这里就不再写出查询脚本样例。

• 第二步：根据用户性能指标创立测试场景

A:并发登陆测试场景

并发登陆750用户/分钟，登陆响应时间在30秒之内。仔细考虑一下，这里的并发登陆750用户/分钟指的是系统能够在1分钟内接受750个用户的登陆请求，而处理的效果如何则在交易终端体现，即登陆响应时间。基于这样的理解，我们把用户性能指标转化为如下的测试场景：

从第一秒钟开始，用loadrunner每秒钟登陆13个用户，并保持socket连接，直到1分钟结束，从终端向系统一共发送750个左右的用户登陆请求，系统在一分钟内建立了750个连接。在终端观察并统计登陆响应时间。如果系统不能响应持续增加的登陆请求或平均登陆响应时间大于30秒，并发登陆测试场景都不能算通过。

B:交易流程测试和查询流程测试：

在这里我们只对系统的业务负载能力做测试（并发处理能力在登陆测试中已经得到考证）。测试场景如下：

在loadrunner中，建立goal-orented的测试场景，以400笔/秒为目标，将调度权交给loadrunner来试图达到这个指标。

C: 综合测试：

交易流程测试和查询流程测试同时进行。

以上的测试场景要求均可在loadrunner中的Controller进行设置完成。

测试场景的创建之后，我们的测试任务更加具体化和清晰化。

• 第三步：运行测试场景，同步监测被测系统性能行为

在loadrunner中的controller中开启unix系统资源计数器，weblogic计数器，DB2计数器，检测系统资源消耗情况，并最终和测试结果数据合并，成为分析图表。

测试结果可在测试执行完毕后，通过loadrunner工具中的Analysis（分析器）获得。

A: 并发登陆测试

依照设计好的测试场景，用loadrunner工具在一分钟内渐增向系统发送登陆请求。分别进行三次，结果如下

表格 2登陆测试结果数据表

注：这里的登陆成功用户指的是系统接受了登陆请求，并建立了连接。平均响应时间在登陆脚本里设置检测点，由loadrunner工具自动获得。

考察系统的瞬时并发处理能力：在完成上一步测试的前提下，逐步增加瞬时并发登陆用户数，直到系统极限。

测试执行结果如下：

表格3瞬时并发登陆测试结果数据表

B: 负载测试

• 交易流程测试：

测试结果如下：

对于通过网络接口发送的批量业务请求，均在性能指标所指定的时间范围内得到请求成功的反馈消息，说明主机已经处理成功。

在通过网络接口发送业务请求的同时，开启IE，通过实际终端界面进行登陆和交易，系统响应时间延长，界面显示和刷新明显变慢，到业务量高峰时期，界面已经不能显示任何信息，处于不可工作的状态。

需求说明的是系统正常工作时，每个界面终端不仅应该能够展示己方的交易信息，还要展示其他交易单位的交易信息和系统信息。因此当交易量大的时候，界面需要展示的信息量是巨大的，这本身对终端界面是一个性能考验。

• 查询流程测试：

本流程测试在交易流程测试之后进行,以利用其生成的数据。

测试结果基本满足性能指标。

• 综合测试

由于交易流程测试的未通过，本测试已经不能执行。

• 第四步：测试结果分析及性能评价

A:并发测试结果分析

根据上述的并发测试响应时间表，我们可以得出以下的结论：

被测系统在一分钟内并不能接受750个用户的登陆请求，其可接受的登陆请求用户数大概为490个左右。在这样的条件下，登陆响应时间在用户要求范围之内。

被测系统的瞬时并发处理能力约为122个用户。

B: 交易流程测试结果分析及性能评价

根据交易流程测试结果可知，通过脚本程序进行业务行为，发送业务请求消息到回收主机处理回应消息，这段时间系统是顺畅的，反应也是迅速的，但是在终端界面却不能即时展现消息。这说明信息的回馈通路在终端界面出现了性能瓶颈。当界面需要在短时间内展示大量交易信息时，已经不能承受负荷。这与终端采用java applet技术有关。

C: 查询流程测试结果分析

查询流程基本符合性能指标。

需要说明的是，实际中，以上每个场景的测试都执行了多次，中间件参数进行了多次的调优。从以上测试的结果分析也可以看出，我们的性能测试瓶颈不是出现在中间件产品上，而是在自身开发的程序上。

•  总结

由以上的实例过程我们可以看出性能测试基本由以下几个步骤进行

1. 系统分析

将系统的性能指标转化为性能测试的具体目标。通常在这一步骤里，要分析被测系统结构，结合性能指标，制定具体的性能测试实施方案。这要求测试人员对被测系统结构和实施业务的全面掌握。

　　2.　建立虚拟用户脚本

将业务流程转化为测试脚本，通常指的是虚拟用户脚本或虚拟用户。虚拟用户通过驱动一个真正的客户程序来模拟真实用户。在这一步骤里，要将各类被测业务流程从头至尾进行确认和记录，弄清这些交易过程可以帮助分析到每步操作的细节和时间，并能精确地转化为脚本。此过程类似制造一个能够模仿人的行为和动作的机器人过程。这个步骤非常重要，在这里将现实世界中的单个用户行为比较精确地转化为计算机程序语言。如果对现实世界的行为模仿失真，不能反映真实世界，性能测试的有效性和必要性也就失去了意义。

　　3. 根据用户性能指标创建测试场景

根据真实业务场景，将单个用户的行为进行复制和控制，转化为多个用户的行为。在这个步骤里，对脚本的执行制定规则和约束关系。具体涉及到交易量，并发时序等参数的设置。这好比是指挥脚本运行的司令部。这个步骤十分关键，往往需要结合用户性能指标进行细致地分析。

　　4. 运行测试场景，同步监测应用性能

在性能测试运行中，实时监测能让测试人员在测试过程中的任何时刻都可以了解应用程序的性能优劣。系统的每一部件都需要监测：客户端，网络，web服务器，应用服务器，数据库和所有服务器硬件。实时监测可以在测试执行中及早发现性能瓶颈。

　　5. 性能测试的结果分析和性能评价

结合测试结果数据，分析出系统性能行为表现的规律，并准确定位系统的性能瓶颈所在。在这个步骤里，可以利用数学手段对大批量数据进行计算和统计，使结果更加具有客观性。在性能测试中，需要注意的是，能够执行的性能测试方案并不一定是成功的，成败的关键在于其是否精确地对真实世界进行了模拟。

在整个性能测试过程中，自动化测试工具的选择只能影响性能测试执行的复杂程度，简便一些或繁杂一些；但人的分析和思考却会直接导致性能测试的成败。所以本篇着重于对性能测试思路的整理。测试工具的介绍可以参看有关压力测试工具的资料。

注1：在本次性能测试案例中，还涉及到健壮性测试和可恢复性测试，限于篇幅，只介绍了并发测试和负载测试。

注2：loadrunner脚本样例并非实际运行脚本，只是为了表示其流程。

• 参考文献

Roger S. Pressman：软件工程实践者的研究方法黄柏素梅宏译机械工业出版社

（ MS Web Application Stress Tool (was) ）

在 MS 的网站上发现了一个挺不错的小东西： MS Web Application Stress Tool (was) 。这是一个 web 应用压力测试工具。它是免费的，这一点很重要，否则 MS 的版权大棒又要来了。

     如今 B/S 结构横行，基于浏览器的应用多如恒河沙数。我们也投入了太多的时间在 web 技术上，我们努力提高开发效率，花大量时间研究各种脚本，轻量级框架， mvc 框架，也许我们可以多投入一些时间关注一下系统执行效率，做做压力测试。

    Was 的使用非常简单，只需要配置好测试脚本，它就可以开始运行，然后给你一个非常详细的报告。脚本的配置有多种方式：

◇      自行编写测试脚本
◇      让 was 记录你在 IE 中的操作
◇      让 was 读取 server 的 log ，生成脚本
◇      指定 url 地址，生成脚本

我的原则是速战速决，对于这样一个小工具，没有必要花太多时间去研究细节，让它自己记录我的 IE 操作吧，下面列出操作过程。

选择菜单： scripts_create_record ，在出现的窗口中选择记录哪里信息，全选也无所谓， next__finish ，系统会弹出一个 IE 窗口，该窗口中的所有 request-response 都会被记录到测试脚本中。需要注意的是该窗口需要比较高的权限，所以请暂时关闭上网助手之类、广告拦截之类的东西。

在该窗口中你可以随意操作你的 web 程序，把要测试的模块都跑到。完成之后直接关闭 IE ，然后点击 ”stop recording” ，一个测试脚本就完成了，实在够傻瓜，不愧是 MS 的东西啊，体贴我这类懒人。
展开刚建好的测试，选择 ”setting” ，指定 Stress level(threads) 的值，同时连接 server 的并发数。 Ok ，选择菜单： scripts_run ，开始折磨你的机器吧。

测试完成之后，选择菜单： view_reports ，可以看到测试结果报告。相当详细，多少次操作，多少数据量，每个页面花多少时间都看得一清二楚，爽啊。

测试报告中，有两个术语很重要，在 ”page summary” 中，有两个指标： TTFB 和 TTLB 。

TTFB Avg 是指：从第一个请求发出到测试工具接收到服务器应答数据的第一个字节之间的平均时间。

TTLB Avg 是指：从第一个请求发出到测试工具接收到服务器应答数据的最后一个字节之间的平均时间。

Matt Maccaux 是BEA的一位门户性能工程师。

　　当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。

图3. 随着负载的增加，系统中两个事务的响应时间曲线

　　注意，在执行队列（图2）开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。

　　为了获得真正可再现的结果，应该将系统置于相同的高负载下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。

　　您可能要问的一个问题是：“如何度量结果？”对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。这称为“flat”测试。

图4. flat测试的情况（所有的用户都是同时加载的）

　　与此相对应的是“ramp-up”测试。

图5. ramp-up测试的情况（在测试期间，用户以稳定速度（每秒x个）增加）

　　ramp-up测试中的用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。因此，flat运行是获得基准测试数据的理想模式。

　　这不是在贬低ramp-up测试的价值。实际上，ramp-up测试对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。

　　Flat测试的问题是系统会遇到“波动”效果。

图6. 一次flat测试中所测得的系统吞吐量的曲线（单位：页面/秒）

　　注意波动的出现，吞吐量不再是平滑的。

　　这在系统的各个方面都有所体现，包括CPU的使用量。

图7. 一次flat测试中所测得的系统CPU使用量随时间变化的曲线

　　注意，每隔一段时间就会出现一个波形。CPU使用量不再是平滑的，而是有了像吞吐量图那样的尖峰。

　　此外，执行队列也承受着不稳定的负载，因此可以看到，随着系统负载的增加和减少，执行队列也在增长和缩减。

图8. 一次flat测试中所测得的系统执行队列的曲线

　　注意，每隔一段时间就会出现一个波形。执行队列曲线与上面的CPU使用量图非常相似。

　　最后，系统中事务的响应时间也遵循着这个波动模式。

图9. 一次flat测试中所测得的系统事务的响应时间

　　注意，每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似，只不过其效果随着时间的推移逐渐减弱。

　　当测试中所有的用户都同时执行几乎相同的操作时，就会发生这种现象。这将会产生非常不可靠和不精确的结果，所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间（有时是几个小时，取决于用户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被“拉平”。或者，可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。

性能规划测试

　　对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如，您可能想知道：如果要以5秒或更少的响应时间支持8,000个当前用户，需要多少个服务器？要回答这个问题，需要知道系统的更多信息。

　　要确定系统的容量，需要考虑几个因素。通常，服务器的用户总数非常大（以十万计），但是实际上，这个数字并不能说明什么。真正需要知道的是，这些用户中有多少是并发与服务器通信的。其次要知道的是，每个用户的“考虑时间”即请求间时间是多少。这非常重要，因为考虑时间越短，系统所能支持的并发用户越少。例如，如果用户的考虑时间是1秒，那么系统可能只能支持数百个这样的并发用户。但是，如果用户的考虑时间是30秒，那么系统则可能支持数万个这样的并发用户（假定硬件和应用程序都是相同的）。在现实世界中，通常难以确定用户的确切考虑时间。还要注意，在现实世界中，用户不会精确地按照间隔时间发出请求。

　　于是就引入了随机性。如果知道普通用户的考虑时间是5秒，误差为20%，那么在设计负载测试时，就要确保请求间的时间为5×（1 +/- 20%）秒。此外，可以利用“调步”的理念向负载场景中引入更多的随机性。它是这样的：在一个虚拟用户完成一整套的请求后，该用户暂停一个设定的时间段，或者一个小的随机时间段（例如，2×（1 +/- 25%）秒），然后再继续执行下一套请求。将这两种随机化方法运用到测试中，可以提供更接近于现实世界的场景。

　　现在该进行实际的容量规划测试了。接下来的问题是：如何加载用户以模拟负载状态？最好的方法是模拟高峰时间用户与服务器通信的状况。这种用户负载状态是在一段时间内逐步达到的吗？如果是，应该使用ramp-up类型的测试，每隔几秒增加x个用户。或者，所有用户是在一个非常短的时间内同时与系统通信？如果是这样，就应该使用flat类型的测试，将所有的用户同时加载到服务器。两种不同类型的测试会产生没有可比性的不同测试。例如，如果进行ramp-up类型的测试，系统可以以4秒或更短的响应时间支持5,000个用户。而执行flat测试，您会发现，对于5,000个用户，系统的平均响应时间要大于4秒。这是由于ramp-up测试固有的不准确性使其不能显示系统可以支持的并发用户的精确数字。以门户应用程序为例，随着门户规模的扩大和集群规模的扩大，这种不确定性就会随之显现。

　　这不是说不应该使用ramp-up测试。对于系统负载在一段比较长的时间内缓慢增加的情况，ramp-up测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使用快速ramp-up测试，系统就会滞后，从而报告一个较相同用户负载的flat测试低的响应时间。那么，什么是确定容量的最好方法？结合两种负载类型的优点，并运行一系列的测试，就会产生最好的结果。例如，首先使用ramp-up测试确定系统可以支持的用户范围。确定了范围之后，以该范围内不同的并发用户负载进行一系列的flat测试，更精确地确定系统的容量。

渗入测试

　　渗入测试是一种比较简单的性能测试。渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。测试运行的时间越久，您对系统就越了解。运行两次测试是一个好主意——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。

　　测试应该运行几天的时间，以便真正了解应用程序的长期健康状况。要确保测试的应用程序尽可能接近现实世界的情况，用户场景也要逼真（虚拟用户通过应用程序导航的方式要与现实世界一致），从而测试应用程序的全部特性。确保运行了所有必需的监控工具，以便精确地监测并跟踪问题。

峰谷测试

　　峰谷测试兼有容量规划ramp-up类型测试和渗入测试的特征。其目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。

　　实现这种测试的最好方法就是，进行一系列的快速ramp-up测试，继之以一段时间的平稳状态（取决于业务需求），然后急剧降低负载，此时可以令系统平息一下，然后再进行快速的ramp-up；反复重复这个过程。这样可以确定以下事项：第二次高峰是否重现第一次的峰值？其后的每次高峰是等于还是大于第一次的峰值？在测试过程中，系统是否显示了内存或GC性能降低的有关迹象？测试运行（不停地重复“峰值/空闲”周期）的时间越长，您对系统的长期健康状况就越了解。

结束语

　　本文介绍了进行性能测试的几种方法。取决于业务需求、开发周期和应用程序的生命周期，对于特定的企业，某些测试会比其他的更适合。但是，对于任何情况，在决定进行某一种测试前，都应该问自己一些基本问题。这些问题的答案将会决定哪种测试方法是最好的。

　　这些问题包括：

• 结果的可重复性需要有多高？
• 测试需要运行和重新运行几次？
• 您处于开放周期的哪个阶段？
• 您的业务需求是什么？
• 您的用户需求是什么？
• 您希望生产中的系统在维护停机时间中可以持续多久？
• 在一个正常的业务日，预期的用户负载是多少？

　　将这些问题的答案与上述性能测试类型相对照，应该就可以制定出测试应用程序的总体性能的完美计划。

参考资料

• WebLogic Server Performance and Tuning ——WebLogic Server产品文档
• WebLogic Server performance tools and information ——WebLogic Server产品文档
• The Grinder: Load Testing for Everyone （dev2dev，2002年11月），作者Philip Aston
• Performance Tuning Guide ——WebLogic Portal产品文档
• dev2dev WebLogic Server Product Center