第8章 应用负载压力测试
8．1 负载压力测试概述
一、负载压力
系统的负载压力指系统在某种指定软件、硬件以及网络环境下承受的流量，例如：并发用户数、持续运行时间、数据量等，其中并发用户数是负载压力的重要体现。例如当一个应用程序在少量用户同时使用的时候，程序可能会正常运行，然而，当有大量用户同时使用时，可能会出现功能失效、性能衰减，甚至系统崩溃的现象。
二、负载压力测试
1．概述
（1）定义
负载压力测试指在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力。
（2）作用
负载压力测试有助于确认被测系统是否能够支持性能需求，以及预期的负载增长等。
（3）内容
负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性能测试、疲劳强度测试、大数据量测试等内容。
2．性能测试
系统的性能是一个很大的概念，对于一个软件系统而言，系统的性能覆盖面包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。性能测试用来保证产品发布后系统的性能能够满足用户需求，在软件质量保证中起重要作用。通常包括以下性能测试策略：
（1）性能评测
①在真实环境下，检查系统服务等级的满足情况，评估并报告整个系统的性能；
②对系统的未来容量作出预测和规划。
性能评测是性能调优的基础。
（2）性能调优
①查找形成系统瓶颈或者故障的根本原因；
②进行性能调整和优化；
③评估性能调整的效果。
通常，性能调优的过程是上述步骤循环执行的过程，以实现目标。
3．负载测试
负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。
4．压力测试
压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在何种负载条件下系统性能处于失效状态，以此来获得系统能提供的最大服务级别的测试。
压力测试是为了发现在何种条件下系统的性能会变得不可接受。压力测试是一种特定类型的负载测试。
5．并发性能测试
（1）并发性能测试的过程
是负载测试和压力测试的过程，逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标、资源监控指标等来确定系统并发性能的过程。
并发性能测试是负载压力测试中的重要内容。
（2）并发性能测试的分类
从一个完整解决方案的角度考虑，并发性能测试概括为以下3类：
①应用在客户端性能的测试；
②应用在网络上性能的测试；
③应用在服务器上性能的测试。
6．疲劳强度测试
通常是采用系统稳定运行情况下能支持的最大并发用户数，或日常运行用户数，持续执行一段时间业务，保证达到系统疲劳强度需求的业务量，通过综合分析交易执行指标和资源监控指标，来确定系统处理的最大工作强度性能的过程。通常利用疲劳强度测试来模拟系统日常业务操作。
7．大数据量测试
（1）独立的数据量测试
独立的数据量测试指针对某些系统存储、传输、统计、查询等业务进行的大数据量测试。
（2）综合数据量测试
综合数据量测试上指和压力性能测试、负载性能测试、疲劳性能测试相结合的综合测试。
三、负载压力测试目的
负载压力测试目的是一个很重要的问题，也是测试前首先要考虑的问题。一些类似“要花多少时间做完一笔交易；什么样的配置提供了最好的性能；系统能在无错情况下承担多大及多长时间的负载；这些升级对系统性能影响多大”的问题，决定了测试的目的，可以概括为以下几个方面：
1．在真实环境下检测系统性能，评估系统性能以及服务等级的满足情况
（1）概述
决策者需要模拟系统负载压力，预见软件的并发承受力，这是在测试阶段就应该解决的重要问题。一个企业自己组织力量或委托软件公司代为开发的应用系统，在生产环境中实际使用起来以后，往往会产生的问题，即这套系统能不能承受大量的并发用户同时访问，该问题是系统负载压力需求的体现。
此处强调在真实环境下检测系统性能。在实施过程中可能认为这样做会遇到很多阻力，可采用“模拟环境”来做测试，该环境指与实际真实应用环境基本等级保持一致的测试环境。
（2）举例
每月20日左右是市话交费的高峰期，收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生的费用，然后收取现金并将此用户修改为已交费状态。简单的两个步骤，当成百上千的终端同时执行这样的操作时，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是严峻考验。决策者在测试阶段就需模拟系统负载压力，预见软件的并发承受力。
2．预见系统负载压力承受力，在应用实际部署之前，评估系统性能
检测系统性能强调对系统当前性能的评估，通过评估，可在应用实际部署之前，预见系统负载压力承受力。该测试的意义在于指导系统总体设计，既可避免浪费不必要的人力、物力和财力，又避免硬件和软件的设计不匹配，使系统具有更长、更健壮的生命力。预见系统负载压力承受力，这是在测试阶段就应该解决的重要问题，需要借助自动化的负载压力测试工具。这里强调在真实环境下检测系统性能，在实施过程中大家认为这样做会遇到很多阻力，在这种情况下，我们需要使用一种“模拟环境”来做测试，这种环境是指与实际真实应用环境基本等级保持一致的测试环境。
3．分析系统瓶颈、优化系统
系统性能检测和预见为分析系统瓶颈和优化提供了原始数据，打好了基础。
（1）系统瓶颈
①概述
负载压力测试中，“瓶颈”用来描述那些限制系统负载压力性能的因素。系统瓶颈指应用系统中导致系统性能大幅下降的原因。瓶颈大大降低了系统性能，测试工程师的职责之一，就是降低或者消除系统中的瓶颈。一般情况下，发现瓶颈并找出原因并不容易。很多时候，可能无法准确定位系统瓶颈之所在。
②定位
瓶颈可能定位在硬件中，也可能定位在软件中。
a．瓶颈定位于软件中（软件瓶颈）
可能定位在开发的应用程序中，也可能定位在操作系统或者数据库内部，数据库和操作系统的开发者们都一直在测试其产品的新版本，以期能尽其所能地排除产品中存在的所有瓶颈。
b．瓶颈定位于硬件中（硬件瓶颈）
硬件中的瓶颈可能非常容易排除，通常，解决硬件瓶颈的方法只是简单地向系统中添加CPU、磁盘或者内存等，如果硬件瓶颈由于系统缓沖区设计或内存总线造成，通常无能为力。
③优先解决软件瓶颈的原因
硬件瓶颈与软件瓶颈相比，更建议先解决软件瓶颈，原因有以下三个方面：
a．软件瓶颈往往导致系统性能衰减更快，反之，消除软件瓶颈，系统性能提升更快；
b．人为因素更易导致软件瓶颈，要消除软件瓶颈，开发人员会更主动，且可节省资源；
c．盲目增加硬件则无形中增加维护费用，将来，软硬件不匹配的问题终究会暴露出来。
（2）负载压力性能问题的类型
优化调整系统是在发现瓶颈，故障定位之后要完成的事情，实现优化后即可消除瓶颈，提高性能。将负载压力性能问题分为两类：
①需要优化的性能问题
该类问题可导致系统性能大幅度下降，或者给系统造成破坏。
②非系统优化所能解决的性能问题
注意：此处讨论的是前者，导致系统性能下降的因素来自许多方面，例如I/O过载、内存不足、数据库资源匮乏等。优化调整即是对症下药。
（3）优化系统
系统优化调整领域，有许多指导性文件。各组成部分的最优并不代表系统性能可以达到最优，各组成单元都具备一些调优指标，各指标的调整并非最大或最小就好，也很少存在在某个范围就最好的情况。给测试工程师的建议是，调优的最终目的是各个指标的调整取得系统的平衡点，也即达到系统性能的最佳点。
由此可知，负载压力测试将为企业项目的实施提供信心，帮助用户正确地进行容量规划，实现软硬件投资合理化，最终交付高质量的系统，避免项目投产失败，保证用户的投资得到相应的回报。
四、负载压力测试策略
1．类型
负载压力测试可以采取利用手工进行测试和利用自动化负载压力测试工具进行测试两种测试策略。下面对这两种进行具体描述：
（1）手工测试
多数工程师掌握手工测试技巧，但该方法需要大量的人员和机器设备，且测试人员的同步问题无法解决，更无法捕捉程序内部的变化情况。
（2）利用自动化负载压力测试工具进行测试
利用自动化负载压力测试工具进行测试可以很好地手工测试的问题。利用自动化负载压力测试工具可以在一台或几台PC机上，模拟成百或上千的虚拟用户同时执行业务的情景，通过可重复的、真实的测试能够彻底地度量应用的性能，确定问题所在。
负载压力测试的发展趋势是，利用自动化的测试工具进行测试。当然在没有工具的情况下，也可以通过手工测试对系统承受负载压力情况做一个近似的评估。
2．自动化测试工具
利用自动化测试工具进行负载压力测试的策略，分别如下：
（1）利用商业化测试工具进行测试
利用商业化测试工具进行测试是进行负载压力测试的主要手段，适用范围非常广，一般都经过长时间的市场检验，测试效果得到业界的普遍认可，测试结果具有一定的可比性，并且厂商一般都能提供很好的技术支持，其版本的升级也会得到保证，但是商业化的自动化测试工具一般价格较高。
（2）利用开放资源测试工具进行测试
①开放资源概述
开放资源指用户不侵犯任何专利权和著作权，以及无需通过专利使用权转让，就可获取、检测、更改的软件源代码，即任何人都有权访问、修改、改进或重新分配源代码。开放资源的理念为，在已存在的工具上共同开发时，最终产品会更加先进，即很多企业和个体都会从中获益。开放资源的最大优点为测试工具免费。
②开放资源性能测试工具
最流行的开放资源性能测试工具为：开放系统测试体系OpenSTA、TestMaker和JMeter。这些工具中的每个都能提供完成负载压力测试所需的功能，现存的多种开放资源测试工具都可获得。举例如下：
a．开放系统测试体系——OpenSTA（http://portal.openstA.org/）
第一，简介
OpenSTA是Windows平台、分布式的软件测试体系，基于CORBA。能产生数百或数千个虚拟用户，最初用于测试基于Web应用软件。此工具还为用户响应时间和平台应用软件的资源占用信息监控提供图形化标准。
第二，脚本语言
OpenSTA具有一种简单的脚本语言，即脚本控制语言（SCL）。SCL同商业性能测试工具一样，使用户能够创建测试脚本，能将输入数据参数化，能从外部文件读入参数数据。OpenSTA的脚本模型界面如图8-1所示。
图8-1 OpenSTA脚本模型界面
b．TestMaker（http://www.pushtotest.com/）
第一，简介
一种基于Java的架构，能够创建测试代理，以用于衡量应用软件和Web服务器的性能。TestMaker可在Windows、Linux和UNIX平台上运行，可用其创建针对Web应用的测试案例，而不管这些应用是基于J2EE平台还是.NET平台。支持各种不同的协议，例如HTTP/HTTPS、TCP/1P、SOAP以及XML。
第二，脚本语言
TestMaker的脚本语言是一种开放资源语言，称为Jython。Jython是Python语言的Java实现形式。Jython给开发者提供了所有的Java对象和Python的面向对象环境。TestMaker包含一个代理日志，同商品化测试工具所提供的功能类似。
c．ApacheJMeter（http://jakartA.apache.org/jmeter/）
第一，简介
一种纯粹的Java应用软件，用于测试功能和衡量性能。JMeter最初基于Apache Tomcat设计，用于测试Web应用软件的性能，但目前，ApacheJMeter的应用更为开放，可同时用于功能测试和负载压力测试。应用该软件可测试Java对象、JDBC、数据库、Pert脚本、Web服务器和应用服务器等。
第二，特点
同商品化测试工具，ApacheJMeter的代理记录可以记录浏览器和Web服务器之间的通信，并且，由于JMeter是100%Java，故其不受平台约束。
（3）自主开发工具测试
自主开发测试即开发自己的负载压力测试程序或者工具。
例如，一简单的Web应用测试工具可按如下步骤构建：
①首先编写一对各模拟客户机运行一个线程的程序。各线程需要与服务器通信，可能使用Java、Net、URL类。该方法能够模拟基本的HTTP客户机，可以执行GET和PUT。各线程需要做的就是发送HTTP请求，收集回复。该组行动可以相当容易地抽象到一个单独的配置文件中，很快地，就得到一个基本的负载测试工具；
②同时可能需要增加一些配置选项以确定响应时间，运行多少个线程，同时开始，还是慢慢增加负载，还需要对与服务器的交互计时，因为响应时间是要测试的核心内容。
五、产品生命周期中负载压力测试计划
在项目的不同阶段都需要进行负载压力性能测试，而测试需要必要的资源，故应该为此制定相应的计划。为了能确保系统负载压力性能满足需求，提供了以下计划安排：
1．在需求分析中充分关注负载压力性能
在需求分析阶段，主要焦点是为系统中共享的和有限的资源进行需求分析。例如，一个网络联接既是共享的又是有限的资源；一个数据库表是一个共享的资源：线程是一个有限的资源。如果没有正确的设计，这些在以后的各阶段将引发严重问题。
为突出负载压力性能需求分析，不同的设计选择对于负载压力性能的影响不同。测试工程师需要掌握负载压力性能目标设计方法，同时应该具备与确定负载压力性能需求相关的体系结构资料，需求分析应与体系结构分析结合进行。
2．从设计中得到负载压力性能指标
设计者应清楚了解不同设计对负载压力性能的影响，在设计的各方面应充分考虑负载压力性能设计各方的意见，给出负载压力性能的预期指标。应该注意以下几点:
（1）如果设计中系统应用了第三方产品，例如中间件或者数据库产品，则应要求第三方产品提供商能够对其产品进行性能验证和设计，识别与其产品有关的负载压力性能问题；
（2）为突出负载压力性能的重要性，在预算方面也应留出专门资金；
（3）设计中还应考虑应用规模和数据量的可升级性。应用分布的规模可能依赖于分布组件的需求级别、事务处理机制和模式等，数据量的升级将要求设计中包含专门处理大数据集的内容。
3．开发阶段创建一个负载压力性能测试环境
开发阶段开始时的负载压力性能任务是建立负载压力性能测试环境。需进行以下工作：
（1）确保合理精确的测试环境，并且此环境可重用；
（2）为测试环境制定规则的负载压力性能测试时间表，如测试环境是共享的，负载压力性能测试不能与其他活动同时发生；
（3）选择一个负载压力性能测试工具。
4．验收阶段在多等级范围内测试并调优
测试要如实表现系统的主要应用，测试系统的可升级性。例如，可确定共享资源如何响应增长的负载，也可确定受限资源在哪个阶段开始用尽或者成为瓶颈。验收测试结果可以统计负载压力性能、比较负载压力性能，以及报告异常，提供分析依据。
5．运行阶段持续监控系统负载压力性能
监控系统在正常运行状态下的负载压力性能，识别系统性能的倾向，确定何种条件下负载压力性能超过可接受范围等。
六、负载压力测试中的盲点
1．产生原因及后果
许多负载压力测试工具存在“盲点”，会给使用工具的测试工程师一种盲目的安全感。这个“盲点”就是在负载压力测试中，不进行功能校验，当功能错误发生时，测试工具不能够记录产生的错误；目前分布式应用部署结构、Web技术的发展等极大地扩大了这些“盲点”发生的可能。
忽视这些“盲点”，必然会导致结果的不可信，甚至导致结果有害。
2．解决办法
负载压力测试期间必须要进行必要的功能内容校验。只有在负载压力测试过程中记录所有虚拟用户的操作，及服务器的响应，才有助于判断功能是否错误。目前有些负载压力测试工具能够将负载压力测试与功能校验融为一体，以尽量减少此“盲点”。如果使用的工具不具备此功能，则须借助于辅助手段来克服“盲点”。
8．2 负载压力测试解决方案
一、并发性能测试
系统的负载压力主要包括并发负载、疲劳强度以及大数据量等。并发对一个系统来讲，某些业务操作对特定角色用户来讲存在着很大的同时操作的可能性。
1．简介
系统的并发性能是负载压力性能最主要的组成部分。多数系统客户端大量的并发操作可提高网络的吞吐量，同时也加剧了服务器资源互斥访问冲突，加大数据库死锁的可能。该负载压力轻则会导致系统性能低下，重则会对系统造成破坏。因此并发性能的测试对于保证系统的性能非常关键。
在并发性能测试过程中，关注点包括客户端的性能、应用在网络上的性能以及应用在服务器上的性能。测试是要定位问题，目的是为了解决问题，这些关注点正是定位问题的必要条件。
2．应用在客户端性能的测试
在客户端模拟大量并发用户执行不同业务操作，达到实施负载压力的目的。
（1）模拟机制
采用负载压力测试工具来模拟大量并发用户，模拟机制如图8-2所示，主要组成部分包括主控台、代理机以及被测服务器，各部分采用网络连接。主控台负责管理各个代理以及收集各代理测试数据，代理负责模拟虚拟用户加压。在每次并发性能测试中，只有一台主控台，但可有多个代理。
图8-2 模拟机制
（2）模拟方法
总原则是最大限度地模拟真实负载压力。要做到该点，是对测试工具的考验和测试工程师经验与智慧的考验。以LoadRunner负载压力测试工具为例，阐述如何模拟真实负载压力。
①创建方案
方案用以模拟现实生活中用户的方式，包含有关如何模拟实际用户的信息：虚拟用户（Vuser）组，Vuser将运行的测试脚本，以及用于运行脚本的负载生成器计算机。
a．创建常规手动方案
如果选择创建常规手动方案，会将选择的各脚本分配给Vuser组，然后，可为各Vuser组分配多个Vuser。可指示某个组中的所有Vuser在同一台负载生成器计算机上运行相同的脚本，也可为组中的各Vuser分配不同的脚本和负载生成器。使用百分比模式创建手动方案，可以定义方案中要使用的Vuser总数，并为每个脚本分配负载生成器和占总数一定百分比的Vuser。
b．设计面向目标的方案
在面向目标的方案中，可定义所希望实现的测试目标，LoadRunner将根据定义的目标自动创建一个方案。在一个面向目标的方案中，可以定义五种类型的目标：虚拟用户数、每秒点击次数（仅WebVuser）、每秒事务数、每分钟页面数（仅WebVuser）或事务响应时间。五种类型目标如下：
第一，虚拟用户目标类型
测试应用程序可以同时运行多少个Vuser。
第二，每秒点击次数、每分钟页面数或每秒事务数
测试服务器的稳定性。需要指定LoadRunner运行的Vuser范围（最大值、最小值），以及每秒事务数目标类型的“事务名称”。
Controller（测试工具的主控台）将尽量使用最少数量的Vuser来达到定义的目标。如果使用最小Vuser数不能达到该目标，Controller将逐渐增加Vuser数，直到达到所定义的最大数。如果使用指定的最大Vuser数仍不能达到指定的目标，Controller将继续增加Vuser数，并再次执行方案。
第三，事务响应时间目标类型
测试在期望的事务响应时间内可以同时运行多少个Vuser，在脚本中指定想测试的事务的名称以及LoadRunner要运行的Vuser数量范围。指定的“事务响应时间”应是一个预定义的阈值，例如，如果希望用户在5秒钟之内登录到某个电子商务站点，请将可接受的最长事务响应时间指定为5秒。
将最大和最小Vuser数设置为希望能够同时提供服务的最大和最小用户数。如果方案没有达到定义的最大事务响应时间，则服务器能够在合理的时间间隔内，对想要同时提供服务的指定数量的用户作出响应。如果在仅执行了部分Vuser后就达到定义的响应时间，或如果接收到消息，提示如果Controller使用定义的最大Vuser数，响应时间将超出指定值，则应考虑修补应用程序或升级服务器的软硬件。
②方案计划
方案的主要内容是确定如何开展测试，以准确描绘用户行为（操作类型和这些操作的计时等，由Vuser脚本表示）。注意如下：
a．可在一段延迟之后开始执行方案，可指定LoadRunner自发出Run命令以来等待的分钟数，也可指定让方案开始的特定时间；
b．使用计划生成器，可对手动方案进行计时设置限制方案的执行持续时间，或Vuser组在方案中的持续时间。对于手动方案，还可规定在某一时间段内LoadRunner启动和停止的Vuser的数量。在指定的时间量内，可以指定LoadRunner应同时启动/停止Vuser组中所有的Vuser，还是仅启动/停止一定数量的Vuser；
c．Vuser脚本中的集合点将干扰已计划好的方案。如果脚本包含集合点，则方案将不会按计划运行。
③方案运行期间
方案运行期间可通过使用集合点指示多个Vuser同时执行任务。集合点可在服务器上创建密集的用户负载，并使LoadRunner能够测量服务器在负载状态下的性能。通过创建集合点，可以确保多个Vuser同步操作。当Vuser到达某个集合点时，会被Controller滞留在该处。当达到要求的Vuser数或者经过一段指定的时间后，Controller就会从集合中释放Vuser。
a．影响服务器的负载级别
通过使用Controller，可根据以下选择来影响服务器的负载级别：
第一，选择在方案运行过程中活动的集合点；
第二，选择加入每个集合的Vuser数。
b．控制服务器上负载峰值的过程
第一，创建Vuser脚本，插入必需的集合点；
第二，创建方案；
第三，向方案中添加Vuser组时，LoadRunner扫描与该组相关的脚本，在其中搜索集合点的名称，并将这些名称添加到“集合信息”对话框中的列表里。如果创建另外一个运行相同脚本的Vuser组，Controller会将该新的Vuser添加到集合中，并更新列表；
第四，设置模拟用户负载的级别；
第五，通过选择将加入到方案中的集合点，以及加入每个集合的Vuser数，可以确定负载的精确级别；
第六，设置集合的属性；
第七，对于各集合，都可设置集合策略；
第八，运行方案。
c．方案中需要注意以下几点：
第一，在运行方案之前，可以同时配置方案的负载生成器和Vuser行为。
虽然默认设置与大多数环境对应，但是LoadRunner允许修改这些设置，以便自定义方案行为。这些设置适用于所有未来的方案运行，并且通常只需设置一次。如果全局方案设置与单个负载生成器的设置不同，则负载生成器设置将替代全局方案。
第二，此处讨论的设置与Vuser运行时的设置无关。
适用于单个Vuser或脚本的设置，包含有关日志记录、思考时间、网络、迭代数和浏览器的信息。LoadRunner导出模式允许配置LoadRunner代理程序和其他LoadRunner组件的其他设置，称为“专家模式”。测试过程中，占主导地位的仍是测试工程师。
测试工程师只有程序设计和开发工具的知识是不够的，必须要懂得系统运转的机理，具备应用平台、软件架构、数据库系统以及网络环境等方面的知识，才能做到尽量分析错误和定位错误。例如，当对关键功能点录制脚本时，不但要掌握功能点完成的任务，还要熟悉功能的业务运行模式，这就需要测试工程师有业务操作背景。
3．应用在网络上性能的测试
（1）简介
该部分主要包括两部分内容，应用网络故障分析和网络应用性能监控。通过测试，可以做到以下几点：
①优化性能；
②预测系统响应时间；
③确定网络带宽需求；
④定位应用程序和网络故障。
（2）应用网络故障分析
应用网络故障分析的测试目标是显示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。
①网络故障分析工具可解决的问题：
a．使应用跨越多个网段的活动过程变得清晰；
b．提供有关应用效率的统计数据；
c．模拟最终用户在不同网络配置环境下的响应时间，决定应用投产的网络环境。
②网络故障分析工具的工作机理
“多个捕捉点，一个分析”。捕捉点即“Agent”，利用主控台“Agent Manager”进行分析，Agent被动监听数据包来实现实时数据采集，Agent Manager完成对所跟踪到的数据的分析，可以自由地将捕捉代理放在不同的平台上如Windows或者UNIX。
a．网络故障分析工具工作机理如图8-3所示，主控台为Management Console，捕捉点为代理探针Probe。
图8-3 网络故障分析工具工作机理
b．典型的Web架构应用部署图如图8-4所示，它可以在应用逻辑路径上进行多点数据采集，并且在任何两个节点间进行数据整合，测量分段的响应时间，分析应用故障。
图8-4 Web架构应用部署图
③辅助做网络故障分析的信息
a．监控不同探针之间的连接状态，传输的字节数以及通信往返行程次数。如图8-5所示，206.40.55.195为浏览器，www.optinal.com为Web服务器，其上各有一个探针，将网络分为两段，分别是Primary和Secondary。
图8-5 探针之间的连接
b．会话性能概要，监控哪段网络延迟大，带宽对网络双向性能的影响，节点用于处理和用于传输的时间等。
c．服务器与客户端之间帧传输情况统计，可以监控到与应用相关的帧的分布，对每个帧可以与相关的数据包关联，并且可以对帧解码。
d．服务器与客户端之间传送包信息统计，监控包的详细信息，并且可以将包与帧及线程相关联。
e．线程信息统计，监控线程的内容和生存周期，以及线程与数据包的关系。
f．负载的高峰时刻，监控到负载的平均值以及高峰值，并且高峰时刻可以与相关的线程、数据包、帧相关联。
④故障错误总结
a．应用级错误：HTTP，FTP，DNS，FTP，No response seen，repeated DNS request…
b．TCP错误：retransmissions，missing data，frame out of sequence，connection errors，resets…
c．IP错误：missing fragment，missing fragment data…
d．其他错误：ICMP，Improper frame…
（3）网络应用性能监控
①网络应用性能监控的目标
它的目标是在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；何种应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序会导致系统瓶颈或资源竞争。
②监控工具
利用工具进行网络应用性能监控，监控探针可部署在整个应用范围内，如图8-6所示。
图8-6 探针布署的应用范围
监控工具主要包括以下部分：
a．探针：采集与存储数据，并根据应用对数据进行分类，设置的原则是根据网络组成和监控要求；
b．探针管理器：管理配置探针，设定数据采集与上传时间，合并收集的数据；
c．时间服务器：对探针进行时针同步；
d．交互界面：数据展示平台。
③用户关心的需要进行网络监控的问题
a．分析关键应用程序的性能；
b．定位问题的根源是在客户端、服务器、应用程序还是网络；
c．哪些应用程序占用大量带宽；
d．哪些用户产生最大的网络流量。
④网络应用性能监控包括的内容
a．应用监视：1500多种应用及15种定义模式、网络的硬件设备、网络应用的流量和流量的拓扑结构；
b．关键特性：客户和服务器通信量、应用响应时间和资源应用的业务水平等；
c．按会话统计传输负载：测试应用和会话级响应时间，以及自动为通过网络中每一个联网设备的各应用程序生成负载图；
d．应用、会话级、事务响应时间；
e．瓶颈：在测试延迟被引入网络的地方。；
f．趋势分析：应用在网络上的性能测试要得到哪些指标的值，以及如何分析结果值。
4．应用在服务器上性能的测试
（1）简介
此处涉及的“测试”指对服务器执行监控。监控的内容主要包括操作系统、数据库以及中间件等。目前监控的手段可采用工具自动监控，也可使用操作系统、数据库、中间件本身提供的监控工具。
（2）利用工具监控的优点
①减少故障诊断和分析时间；
②减少手工定位的时间和避免误诊；
③在问题发生前定位故障；
④验证可达到的性能水平和服务水平协议；
⑤持续的服务器、数据库和应用性能和可用性监控；
⑥故障诊断和恢复：自动报警、故障恢复程序、故障恢复信息；
⑦服务器、应用可用性和性能报告。
操作系统、数据库、中间件本身提供的监控工具有时采用命令行的方式，有时具备友好的图形界面，也有一些用于特定系统的监控工具。例如，Saloris监控服务器资源占用可以使用vmstat或者iostat命令，Web应用中间件Websphere的监控可以采用系统本身提供的Web页面的监控工具，当然也有一些用于特定系统的监控工具，例如用于AIX操作系统的监控工具nmon32。
（3）操作系统的监控
涉及后台重要服务器操作系统的监控。如果系统采用负载均衡机制，则有必要验证负载均衡是否能处理大的客户端压力，是否能正确实现负载均衡。操作系统有很多种类型，监控的指标不尽相同，但对于主流的操作系统，最关注的指标包括：CPU、内存以及硬盘。
（4）对数据库的监控
非常复杂，不同数据库监控的指标存在差异。
①共性的指标
a．监控数据库系统中关键的资源；
b．监测读写页面的使用情况；
c．监控超出共享内存缓冲区的操作数；
d．监测上一轮询期间作业等待缓沖区的时间；
e．跟踪共享内存中物理日志和逻辑日志的缓冲区的使用率；
f．监控磁盘的数据块使用情况以及被频繁读写的热点区域；
g．监控用户事务或者表空间监控事务日志；
h．监控数据库锁资源；
i．监测关键业务的数据表的表空间增长；
j．监控SQL执行情况。
②举例
以Oracle资源监控为例，重点关注的内容包括内存利用、事件统计、SQL分析、会话统计。
a．内存利用
第一，db block gets；
第二，db block changes；
第三，global cache gets；
第四，global cache get time。
b．事件统计
第一，enqueue waits；
第二，shared hash latch upgrades-no wait；
第三，shared hash latch upgrades-wait；
第四，redo log space wait time。
c．SQL分析
第一，table scan rows gotten；
第二，table scans（long tables）；
第三，table scans（short tables）；
第四，index fast full scans（full）。
d．会话统计
第一，session logical reads；
第二，session stored procedure space；
第三，CPU used by this session；
第四，session connect time。
注意：中间件服务器包括Web服务器，例如Apache；Web应用服务器，例如Websphere和WebLogic；应用服务器，例如tuxedo等。国产中间件目前也在广泛地使用，例如TongLink等。中间件是客户端负载压力的直接承受者，中间件的资源使用得是否合理，与客户端以及与后台数据库服务器连接是否合理，都直接影响系统的性能。
二、疲劳强度测试
疲劳强度对系统来讲也是一种负载，强调的是长时间的考核。
1．日常业务疲劳强度模拟
系统日常业务可能负载并不大，但特点是持续时间长，比如正常情况下每天持续8小时，而对某些系统，24小时都需要运转，这就是系统不能承受长时间疲劳运行。通过验证此项性能的测试即疲劳强度测试，可知系统能否在正常负载情况下长时间运行。日常业务疲劳强度测试，即模拟系统的日常业务，持续执行“一段时间”，暴露系统的性能问题。
2．高峰业务疲劳强度模拟
通常系统运行都有其高峰期。疲劳强度测试必须要模拟这样的高峰业务。这样的负载对系统进行双重考验，既包括负载，又包括长时间。这里需要对“一段时间”有个合理的解释，该时间指标要满足以下两个主要条件：
（1）该段模拟时间所处理的交易量要达到系统疲劳强度需求的业务量，例如某个系统至少要无故障运行3个月，处理30万笔交易，则所执行的疲劳强度测试就必须保证该交易量，以满足系统对长时间运行过程中所递增的数据量的要求；
（2）在这段测试周期中必须通过加大负载，和尽可能延长测试周期来保证疲劳强度测试。
三、大数据量测试
1．大数据量测试类型
大数据量测试包括独立数据量测试和综合数据量测试两种主要类型。
（1）独立数据量测试
独立数据量测试针对某些系统存储、传输、统计、查询等业务进行单用户大数据量测试。
例如，有些系统存在大量的批处理任务。批处理任务指一次操作对数据库中大量数据进行互斥访问的数据库事务。该类型的事务通常将更新同一数据库表中的数千项乃至更多的数据。通常，批处理任务推荐在系统具有较长空闲时完成（如晚上），以保证不对独立事务造成影响。如果由于业务要求，批处理任务必须与独立事务混合运行，则必须对其加以改造，以减轻对其他事务的影响。
（2）综合数据量测试
综合数据量测试提出“一定的数据量是并发测试与疲劳测试的基础”，在并发测试和疲劳强度测试过程中，如果不考虑数据量对系统性能的影响，无疑会带来缺陷。
例如，模拟某个系统执行“查询”操作，在“并发用户数为100、查询记录数为10000条”负载下，该系统运转正常，性能可接受，但是当负载变为“并发用户数为100、查询记录数为100000条”时，系统将出现长时间无响应现象。因此在测试实施过程中，要采用并发测试、疲劳强度测试以及大数据量测试相结合的综合测试方案。
2．自动生成大数据量
通过以下步骤可解决“大数据量测试需求，但很难在较短的时间内生成大量业务数据”的难题：
（1）首先，可借助自动化测试工具，利用数据库测试数据自动生成工具，例如ESTBytes，确定需要生成的数据类型，通过与数据库连接来自动生成数百万行正确的测试数据；
（2）其次，利用自动化负载压力测试工具，模拟用户业务操作，同时并发数百个或数千个应用产生相关数据，且测试工程师不需要清楚地知道数据表与表之间的关系等细节内容，就可事半功倍。例如要生成订单，不必考虑订单中的信息在数据库内部到底与那些表有关系，简单录制一个用户生成订单的操作，然后模拟大量虚拟用户生成订单数据就可以了；
（3）再次，还可针对某个应用，在了解整个数据库结构的基础上，自主开发数据生成工具，也可利用数据库本身提供的辅助工具来生成数据。
3．大数据量管理
管理这些数据决定了能否成功地实现大数据量测试，大数据管理可以采用手工管理和自动化工具管理两种方式。数据管理工具File-Aid/CS介绍如下：
（1）简介
File-Aid/CS是一套为帮助开发者、测试人员、质量保证团队更加有效地在开发、测试和支持C/S或Web应用中的测试数据管理工具。File-Aid/CS提供数据拷贝、构造子集、数据转换、数据编辑、数据浏览、数据生成、数据比较、数据迁移等功能。运行在WindowsNT、XP、2000、98等平台上，支持Oracle、Microsoft SQL Server、DB2UDB、Sybase和Informix数据库。
（2）功能
我们需要比较一个软件的数据库表中字段格式是否与标准格式相符，可以理解为一种标准符合性测试。借助于这个工具，可以做到下面几点：
①比较数据和数据库结构；
②转换关系数据库数据成XML数据；
③比较XML数据与关系数据库数据；
④比较XML文件；
⑤利用提供的数据迁移功能，可实现大数据跨平台迁移。
8．3 负载压力测试指标
一、简介
1．类型
各测试工具都会提供许多测试指标，有些都具备，有些是某个工具独有的。在选择工具时可以综合考虑其优劣，关键在于能够提供满足测试目的指标的工具。通常，可选择的指标包括以下几类：
（1）客户端交易处理性能指标；
（2）服务器资源监控指标，例如：UNIX；
（3）数据库资源监控指标，例如：Oracle；
（4）Web服务器监控指标，例如：Apache；
（5）中间件监控指标，例如：TUXEDO等。
2．注意事项
（1）指标的选择并非越多越好，如果测试需求仅仅是系统的负载压力性能评测，则只要重点关注客户端交易处理性能指标就足够，许多工具可以胜任这项任务；
（2）如果测试需求关心系统后台服务器承受负载压力的能力，重点是监控服务器、数据库、中间件等资源的使用情况；
（3）较高级别的性能调优是在系统故障定位的前提下实施的，这时，要测试的指标要求非常全面，包括客户端交易处理性能指标、服务器资源监控指标、网络品质指标，以及应用在网络上的故障定位指标等。这里包含了两层含义，一层是系统的负载压力故障定位，另一层是系统应用实际部署故障定位。前一层是后一层的基础。
（4）要完成这该工作，有时需要利用多种类型测试工具，如：负载压力测试工具、网络品质监控工具、应用网络故障定位工具、服务器资源监控工具等。
二、交易处理性能指标
1．并发用户数指标
2．交易处理指标
（1）平均事务响应时间；
（2）每秒事务数；
（3）每秒事务总数；
（4）事务摘要；
（5）事务性能摘要；
（6）事务响应时间（负载下）；
（7）事务响应时间（百分比）；
（8）事务响应时间（分布）。
3．Web请求指标
（1）每秒点击次数；
（2）点击次数摘要；
（3）吞吐量；
（4）吞吐量摘要；
（5）HTTP状态代码摘要；
（6）每秒HTTP响应数；
（7）每秒下载页面数；
（8）每秒重试次数；
（9）重试次数摘要；
（10）连接数；
（11）每秒连接数；
（12）每秒SSL连接数。
4．Web页面组件指标
（1）激活网页细分；
（2）页面组件细分；
（3）页面组件细分（随时间变化）；
（4）页面下载时间细分；
（5）页面下载时间细分（随时间变化）；
（7）第一次缓冲时间细分（随时间变化）；
（8）已下载组件大小。
三、服务器操作系统资源监控
1．UNIX操作系统
UNIX操作系统资源监控指标如表8-1所示。
表8-1 UNIX操作系统资源监控指标
Linux操作系统与UNIX操作系统类似。
2．Windows操作系统
Windows操作系统资源监控指标如表8-2所示。
表8-2 Windows操作系统资源监控指标
针对操作系统的监控，如果需要监控磁盘管理、文件系统、内存、CPU等方面内容，监控建议如下：
（1）磁盘管理
①采集物理读/写和逻辑读/写的信息；
②收集操作系统和其他平台上的磁盘忙信息；
③监控I/O。
（2）文件系统
①显示每个文件系统的使用率，检测文件系统空闲空间的大小；
②剪裁文件系统——删除指定的CORE文件和其他文件；
③显示文件系统的mount on device、type、size等内容；
④可以监控特殊的文件系统，如NFS，CD-ROM；
⑤检测特定文件的存在及超出特定期限的文件存在。
（3）內存
①显示可用的内存数量；
②决定当前的内存短缺量；
③帮助分析内存问题；
④显示内存的实存、所有虚存和kernel的状态等信息。
（4）CPU
①记录CPU的使用率；
②监测CPU参数，包括CPU idle，CPU waits，CPU system usage，CPU user usage，run queue length；
③显示CPU context switches的总数；
④显示CPU处理系统任务和完成用户任务的时间比例。
四、数据库资源监控
1．Oracle
Oracle资源监控指标如表8-3所示。
表8-3 Oracle资源监控指标
2．Sysbase
Sysbase资源监控指标如表8-4所示。
表8-4 Sysbase资源监控指标
3．DB2
DB2资源监控指标如表8-5、表8-6及表8-7所示。
表8-5 DB2资源监控指标（数据库管理）
表8-6 DB2资源监控指标（数据库）
表8-7 DB2资源监控指标（应用程序）
4．SQLServer
SQLServer资源监控指标如表8-8所示。
表8-8 SQLServer资源监控指标
数据库系统的监控，如果需要监控共享内存缓沖区、会话、磁盘等方面的内容，以下为一些监控建议：
（1）监控超出共享内存缓冲区的操作数
按照该基准，可以对缓冲区进行额外的调整，以便更好地支持实际系统的运行需要，提高用户生产效率。
（2）扩展的会话/用户检查以及参数控制
利用扩展的会话/用户检查以及参数控制功能，发出警报，可以发现过多的不合理顺序的扫描操作。根据这些信息，分配附加的资源，或者要求修改其应用程序，以降低对系统资源的要求。也就是说要制定更精确的资源容量计划，以便实现现在和将来的业务运行需要。
（3）磁盘
监控磁盘的数据块使用情况以及被频繁读写的热点区域。通过这些信息可以较容易地平衡在磁盘上数据量的存储分配以及磁盘的I/O分配，有效帮助作好磁盘容量规划，并在当前的磁盘设备上有效地提高数据的读写效率。
五、Web服务器监控
1．Apache
Apache资源监控指标如表8-9所示。
表8-9 Apache资源监控指标
2．IIS
IIS资源监控指标如表8-10所示。
表8-10 IIS资源监控指标
六、中间件服务器监控
1．TUXEDO
TUXEDO资源监控指标如表8-11所示。
表8-11 TUXEDO资源监控指标
2．WebSphere
WebSphere资源监控指标如表8-12与表8-13所示。
表8-12 Web Sphere资源监控指标（队列性能计数器）
表8-13 WebSphere资源监控指标（通道性能计数器）
3．WebLogic
WebLogic资源监控指标如表8-14与表8-15所示。
表8-14 WebLogic资源监控指标（Log Broadcaster Runtime）
表8-15 WebLogic资源监控指标（Server Security Runtime）
8．4 负载压力测试实施
一、负载压力测试实施步骤
测试计划→测试需求分析→测试案例制定→测试环境、工具、数据准备→测试脚本录制、编写与调试→场景制定→测试执行→获取测试结果→结果评估与测试报告。
二、测试计划
1．简介
制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：
（1）构建能够精确地模拟工作环境的测试方案
负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。
（2）了解测试需要的资源
应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。
（3）以可度量的指标定义测试成功条件
明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标不够。
2．负载压力测试计划过程的步骤
（1）分析应用程序
分析应用程序是负载测试计划的第一步。应对硬件和软件组件、系统配置和典型的使用模型有透彻的了解以确保使用的测试环境能够在测试中精确地反映应用程序的环境和配置。
①确定系统组件
绘制一份应用程序结构示意图或从现有文档中提取一份示意图。如果要测试的应用程序是一个较大的网络系统的一部分，应该确定要测试的系统组件。确保该示意图包括了所有的系统组件。一个由许多Web用户访问的联机银行系统如图8-7所示。图中各Web用户连接到同一数据库以转移现金和支票余额。客户使用不同的浏览器，通过Web方式连接到数据库服务器。
图8-7 联机银行系统应用布署
②描述系统配置
增加更多详细信息以完善示意图。描述各系统组件的配置。应当掌握以下信息：
a．连接到系统的用户数；
b．应用程序客户端计算机的配置情况（硬件、内存、操作系统、软件、开发工具等）；
c．使用的数据库和Web服务器的类型（硬件、数据库类型、操作系统、文件服务器等）；
d．服务器与应用程序客户端之间的通信方式；
e．前端客户端与后端服务器之间的中间件配置和应用程序服务器；
f．可能影响响应时间的其他网络组件（调制解调器等）；
g．通信设备的吞吐量以及每个设备可以处理的并发用户数。
例如，在如图8-6所示的示意图中，多个应用程序客户端在访问系统。客户端的配置如表8-16所示。
表8-16 客户端配置内容
③分析使用模型
定义系统典型的使用方式，确定需要重点测试的功能。考虑哪些用户使用系统、每种类型用户数量，和各用户的典型任务。此外，还应考虑任何可能影响系统响应时间的后台负载。
例如，假设每天上午有200名员工登录记账系统，并且该办公室网络有固定的后台负载：50名用户执行各种字处理和打印任务。可以创建一个200个虚拟用户登录访问记账数据库的方案，并检测服务器的响应时间。要了解后台负载对响应时间的影响，可以在运行方案的网络中再模拟员工执行字处理和打印活动的负载。
④任务分布
除定义常规用户任务外，还应该查看这些任务的分布情况，以确定数据库活动峰值期的发生时间，以及负载峰值期间的典型活动。
（2）定义测试目标
①以可度量的指标制定目标
确定负载测试的一般性目标后，应以可度量指标制定更具针对性的目标。为提供评估基准，应精确地确定、区分可接受和不可接受测试结果的标准。例如：
a．一般性目标产品评估
选择Web服务器的硬件。
b．明确目标产品评估
在一台HP服务器和一台NEC服务器上运行同一个包含300个虚拟用户的组。当300个用户同时浏览Web应用程序页面时，确定哪种硬件提供更短的响应时间。
c．测试目标
第一，度量最终用户的响应时间，完成一个业务流程需要多长时间；
第二，定义最优的硬件配置，哪种硬件配置可以提供最佳性能；
第三，检查可靠性，系统无错误或无故障运行的时间长度或难度；
第四，查看硬件或软件升级对性能或可靠性有何影响；
第五，评估新产品，应选择哪些服务器硬件或软件；
第六，度量系统容量，在没有显著性能下降的前提下，系统能够处理多大的负载。
第七，确定瓶颈，哪些因素会延长响应时间。
②确定测试的时间
负载测试应贯穿于产品的整个生命周期。如表8-17所示，此表说明在产品生命周期的各个阶段有哪些类型的测试与之相关。
表8-17 产品生命周期与测试类型
（3）计划方案实施下一步是确定如何实现测试目标。
①定义性能度量的范围
可以度量应用程序中不同点的响应时间。根据测试目标确定在哪里运行Vuser（虚拟用户）以及运行哪些Vuser。
a．度量端到端的响应时间
第一，可在前端运行图形用户界面用户(GUIVuser）或终端用户（RTEVuser）来度量典型用户的响应时间。GUIVuser可以将输入提交给客户端应用程序并从该应用程序接收输出，以模拟实际用户；RTEVuser则向基于字符的应用程序提交输入，并从该应用程序接收输出，以模拟实际用户。
第二，可在前端运行GUI或RTEVuser来度量跨越整个网络（包括终端仿真器或GUI前端、网络和服务器）的响应时间。端到端的响应时间如图8-8所示。
图8-8 端到端的响应时间
b．度量网络和服务器响应时间
可通过在客户机运行Vuser来度量网络和服务器的响应时间。Vuser模拟客户端对服务器的进程调用，但不包括用户界面部分。在客户机运行大量Vuser时，可以度量负载对网络和服务器响应时间的影响。网络和服务器的响应时间如图8-9所示。
图8-9 网络和服务器的响应时间
c．度量GUI响应时间
可通过减去前两个度量值，来确定客户端应用程序界面对响应时间的影响。GUI响应时间：端到端响应时间——网络和服务器响应时间。GUI响应时间如图8-10所示。
图8-10 GUI响应时间
d．度量服务器响应时间
可度量服务器响应请求（不跨越整个网络）所花费的时间。通过在与服务器直接相连的计算机上运行Vuser，可度量服务器性能。服务器响应时间如图8-11所示。
图8-11 服务器响应时间
e．度量中间件到服务器的响应时间
如果可访问中间件及其API，便可度量服务器到中间件的响应时间。可使用中间件API创建Vuser，来度量中间件到服务器的性能。中间件到服务器响应时间如图8-12所示。
图8-12 中间件到服务器响应时间
②定义Vuser活动
根据对Vuser类型的分析以及其典型任务和测试目标来创建Vuser脚本。由于Vuser模拟典型最终用户的操作，因此Vuser脚本应包括典型的最终用户任务。根据测试目标确定要衡量的任务，并定义这些任务的事务。这些事务度量服务器响应Vuser提交的任务所花费的时间（端到端时间）。此外，可以通过在脚本中使用集合点来模拟峰值期活动，集合点指示多个Vuser在同一时刻执行任务。
③选择Vuser
确定用于测试的硬件配置前，应先确定需要的Vuser的数量和类型。要确定运行多少个Vuser和哪些类型Vuser，综合考虑测试目标来查看典型的使用模型。以下为一般性规则：
a．使用一个或几个GUI用户来模拟每种类型的典型用户连接；
b．使用RTEVuser来模拟终端用户；
c．运行多个非GUI或非RTEVuser来生成各用户类型的其余负载。
例如，假设有五种类型的用户，每种用户执行一个不同的业务流程，如表8-18所示。
表8-18 Vuser的数量和类型
④选择测试硬件和软件
硬件和软件应该具有强大的性能和足够快的运行速度，以模拟所需数量的虚拟用户。在确定计算机的数量和正确的配置时，须考虑以下事项：
a．建议在一台单独的计算机上运行测试工具主控台；
b．在一台Windows计算机只能运行一个GUIVuser；而在一台UNIX计算机上则可以运行多个GUIVuser；
c．GUIVuser测试计算机的配置应该尽量与实际用户的计算机配置相同。
各测试组件硬件要求，如表8-19和表8-20所示。要获得最佳性能，应满足表中所列要求。
表8-19 测试机硬件与软件要求（Windows配置要求）
注意：对于一个要运行多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。
有关最新的安装要求，请访问http://www.mercuryinteractive.com/products/loadrunner/technical/（建议在一台单独的计算机上运行测试工具主控台）。
表8-20 测试机硬件与软件要求（UNIX配置要求）
（4）检查测试目标
①简介
测试计划应基于明确定义的测试目标，以下为常规的测试目标：
a．度量最终用户响应时间；
b．定义最优的硬件配置；
c．检查可靠性；
d．查看硬件或软件升级；
e．评估新产品；
f．确定瓶颈；
g．度量系统容量。
②度量最终用户响应时间
查看用户执行业务流程以及从服务器得到响应所花费的时间，例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。一个银行应用程序的负载和响应时间度量之间的关系如图8-13所示。
图8-13 负载和响应时间度量关系
③定义最优的硬件配置
检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可度量不同系统配置下的应用程序响应时间，从而确定哪种设置能够提供理想的性能级别。
例如，可以设置三种不同的服务器配置，并针对各配置运行相同的测试，以确定性能的差异。
a．配置1：200 MHz、64MB RAM；
b．配置2：200 MHz、128MB RAM；
c．配置3：266 MHz、128MB RAM；
④检查可靠性
确定系统在连续的高工作负载下的稳定性级别。可创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。
⑤查看硬件或软件升级
执行回归测试，以便对新旧版本的硬件或软件进行比较。可查看软件或硬件升级对响应时间(基准)和可靠性的影响。应用程序回归测试需查看新版本的效率和可靠性是否与旧版本相同。
⑥评估新产品
可运行测试，以评估单个产品和子系统在产品生命周期中计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。
⑦确定瓶颈
可运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。系统不同点的性能如图8-14所示。
图8-14 系统不同点的性能
⑧度量系统容量
度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定当前容量后，便可确定是否需要增加资源以支持额外用户。响应时间与负载关系如图8-15所示。
图8-15 响应时间与负载关系
三、测试需求分析
负载压力测试需求分析既需要借助于相关的理论知识，又要依靠测试工程师在相关领域的经验积累。下面是一些理论知识及经验方法：
1．测试需求内容
测试需求是应用需求的衍生，且测试用例必须覆盖所有的测试需求，否则，该测试过程就不完整。主要有以下几个关键点：
（1）测试的对象为何，例如“被测系统中有负载压力需求的功能点包括哪些”；“测试中需要模拟哪些部门用户产生的负载压力”等问题。
（2）系统配置如何，例如“预计有多少用户并发访问”；“用户客户端的配置如何”；“使用什么样的数据库”；“服务器怎样和客户端通信”；“网络设备的吞吐能力如何，每个环节承受多少并发用户”等问题。
（3）应用系统的使用模式是什么，例如“使用在什么时间达到高峰期”；“用户使用该系统是采用B/S运行模式吗”等问题。
针对用户提出的问题，一简单的需求回答，如表8-21所示。
表8-21 用户需求与测试目标
2．负载压力测试需求分析原理
（1）80～20原理测试强度估算
①80～20原理
各工作日中80%的业务在20%的时间内完成。例如：每年业务量集中在8个月，每个月20个工作日，每个工作日8小时即每天80%的业务在1.6小时完成。
②举例说明80～20原理如何应用与测试需求分析
去年全年处理业务约100万笔，其中，15%的业务处理中，每笔业务需对应用服务器提交7次请求：70%的业务处理中，每笔业务需对应用服务器提交5次请求；其余15%的业务处理中，每笔业务需对应用服务器提交3次请求。据以往统计结果，每年的业务增量为15%，考虑到今后3年业务发展的需要，测试需按现有业务量两倍进行。测试强度估算如下：
a．每年总请求数为：（100×15%×7＋100×70%×5＋100×15%×3）×2＝1000万次/年；
b．每天请求数为：1000/160＝6.25万次/天；
c．每秒请求数为：（62500×80%）/（8×20%×3600）＝8.68次/秒；
d．服务器处理请求的能力应达到9次/秒。
（2）UCML（User Community Modeling Language）压力需求分析
①UCMLTM概述
a．UCMLTM为一个符号集合，这些符号可创建虚拟系统用法模型，以及描述相关参数；当应用到负载压力性能测试时，这些符号可用于表示工作量分配、操作流程、重点工作表、矩阵和马尔可夫链等。
b．UCML输出的结论图表可有效地应用于文档，甚至是测试计划、测试设计等，还可作为讨论和数据整理的依据；系统分析人员和用户还可以用其回顾和验证工作流程和工作量的需求。
c．UCMLTM给支持负载压力性能测试的复杂数学模型创建了一个直观的可视化模型，对于数学模型，UCMLTM是一种补充，现在至少可以证明这一可视化技术对测试人员、应用用户、开发者、经理和商家来说都是相当直观的。有专门针对UCMLTM的画图工具，除了用SmartDraw画UCMLTM模型，还可应用PowerPoint、Microsoft Visio等软件来画，且我们可为Microsoft Visio和SmartDraw创建符号库。
d．UCMLTM不是一种工业标准，现在还不能证明适用于任何类似IEEE的工业标准或规范。用户可应用其中的全部或部分符号，或者按照需要来进行修改或改进它们。
②UCMLTM的符号
a．基本符号
基本符号可以表示系统应用。许多情况下，一个用法路径可以看作是一个应用会话。
b．数量环
用来回答“多少”“多大频率”问题。圆圈里显示的是一个数或者百分比。数量环如图8-16所示。
图8-16 数量环
c．描述线
描述线是水平的实线，表示activity和用户类型。各描述线标注一个或多个描述内容，来显示用户类型、activity或运行路径。附在描述语句后面的圆括号里的内容是所有同类用户的百分比，或在一定时间段内运行该activity、执行这条路径的用户百分比。有多项标注的activity出现或者同条线上出现相同数量或频率时，使用数量环；当数量或频率附属于一特定activity时，使用圆括号。
描述线主要是用户类型描述线和activity类型描述线
第一，用户类型描述线
用户类型描述线在模型的最左边，表示将要进入已创建的应用的用户类型，例如：基本用户、超级用户、管理员。与用户类型相关的百分比显示了所有用这种类型表示的系统中的用户比例。用户类型描述如图8-17所示。
图8-17 用户类型描述
第二，activity类型描述线
activity类型描述线表示系统的不同类型用户的activity和运行路径。线的上面列出已完成的用户activity，或运行路径所查看的界面。由建模人员决定应该将特定activity的各步骤列出还是简单地给activity命名。记录的关键是各水平线表示毫无转折的到达该activity的直线路径。这条线可分出支路也可合并，表示通过该系统对行动路线的选择。选择特定运行路径的用户的百分比显示在路径始端的数量环里。在模型中任何一个指定点，所有运行路径的用户之和都是100%，与访问站点的人数相同。activity类型描述线如图8-18所示。
图8-18 activity类型描述线
d．同步点
垂直的虚线表示模型中的同步节点。如果同步节点已命名，就将其名字写在线的上方。同步节点用于描述合并。有两种可以用同步节点符号表示的合并，即时间上的合并和运行点的合并。同步点如图8-19所示。
图8-19 同步点
有以下两种可以用同步节点符号表示的合并：
第一，时间上的合并
在进程开始前，先到达同步节点的建模用户必须等待所有其他建模用户都到达此节点。在建立信息系统时非常有帮助。
第二，运行点上的合并
所有建模用户都运行通过了应用中的同一位置，但不一定在同一时间。以网站的注册界面为例，在该例子中，所有用户在被允许访问其他界面之前，必须在同一网页上填写各自的资格鉴定。在开发脚本时鉴别这些运行同步节点是很有帮助的，因为其可以为脚本、草稿、功能、程序等充当普通的开始/关闭点。
注意：在名称后用圆括号插入同步节点类型的注释很有帮助，例如：“同步点1（time）”。
e．选择框
系统运行时，常常要求用户进行一些不会改变其全部行为的选择或数据输入。模型中，用位于运行路径下方的一个虚线框来表示这些选项。选择框如图8-20所示。
图8-20 选择框
选择框需要标注一个词或短语，来描述那些随着用户的改变而变化的选择和数据。特定数据将会记录在模型内的电子数据表中。
f．条件
模型中，条件是用户根据结果来改变其运行路径的节点。举例：假设用户要购买一本书。如果用户查询后，发现它有库存，用户就按照“Yes”路径购买此书，但如果此书无库存，用户就按照“No”路径取消此过程。条件如图8-21所示
g．循环
在运行路径上，虚线的半圆弧表示循环，半圆弧所环绕的活动将重复执行。需要反复的次数或需要重复此行为的用户百分数（不是模型表示的所有用户），标注在数量环里。循环如图8-22所示。
图8-21 条件
图8-22 循环
h．跳出路径
除了运行路径中断的节点以外，构筑用户的跳出非常重要。指向数量环的下划线表示路径在具体某点处，将要跳出系统的用户百分比。所有进入系统的用户都应显示退出。跳出系统的类型应记录在标签上。跳出路径单方式如图8-23所示，跳出路径多种方式如图8-24所示。以下例子显示了从运行路径跳出的多种方式。其中，50%的用户放弃了系统，40%的用户正在退出系统，因此其以首选方式跳出系统（另外的10%从另一个运行路径跳出，没有给出表示）。
图8-23 跳出路径单方式
图8-24 跳出路径多种方式
i．分支
多数应用不局限于直线路径。开始执行同一activity的一组用户，可能只是为以后分支到不同的运行路径中。以下例子显示了一个分支，可以在该分支上选择两条路径中的一条离开主页。分支上用户百分数的和必须等于引起分支的界面上的用户百分比。
如图8-25所示。
图8-25 分支一
一个独立描述线可有多个分支，如图8-26所示。
图8-26 分支二
j．合并
带有分支的运行路径常遇到将不同分支合并到一起的情况。
第一，以下例子显示了两个不同路径合并到Update Billing Information这一activity。同理，合并前的用户的总百分比必须等于合并后的总用户百分比。分支合并如图8-27所示。
图8-27 分支合并
第二，另一个常应用的合并是为了显示不同类型的用户在同一点进入了软件，如图8-28所示。此处，各不同类型的用户用不同的颜色表示，这是为了在以后的模型中，使对应于特定用户组的行为能够通过颜色区分。各用户类型后面都用圆括号标注了其缩写，这些缩写在以后的模型中也可以应用。对那种必须由黑白表示的模型特别有利。
图8-28 不同类型用户分支合并
（3）符号组合User Community模型
基本符号的组合使UCMLTM语言更加强大。通过组合符号，可在一个能形成整个Community的虚拟模型的系统中，表示所有可能的用户运行路径。例如：为在线书店建立一UCMLTM图表。假设此为一个新的应用，所以没有可以分析利用的现存数据。经过一系列的采访，收集了下面的信息。以下是关于用户进入网站的activity和其预期的相关量：
①四种用户类型：新用户（20%），会员（70%），管理员（4%），商家（6%）
②所有用户都从主页进入
③新用户和会员可引导的activity，如下：
a．通过题目、作者、关键字查询书目；
b．向购物车添加一本或多本书；
c．保留购物车以待结算。
④新用户可以开设账户（开设账户后变成会员）
⑤会员可以选择的activity：进入系统、升级账户、项目结算、检查结算状态。
⑥管理员和商家必须从主页进入系统，再从管理员界面开始
⑦管理员可以选择的activity：添加新书、检查结算状态、升级结算状态、取消命令。
⑧商家可执行的报告：库存、上周销售额、上月销售额。
在线书店UCML图表如图8-29所示。
图8-29 在线书店UCML图表
图8-29中包含访问总结中未提到的信息，这些信息是为最初草案而估计的。但不是所有来自于访问总结的信息都囊括进来了。现在图标可反馈到被采访者处，以便确认或改正运行路径和用户量、添加或删除activity。
3．需求分析方法
（1）任务分布图方法
①使用任务分布图方法应关注以下两点：
a．有哪些交易任务；
b．在一天的某些特定时刻系统都有哪些主要操作。
②举例
如图8-30所示，可知：
a．12：00，交易混合程度最高；
b．10：00～12：00是登录高峰期；
c．数据更新业务的并发用户数最大为90。
图8-30 任务分布图
（2）交易混合图方法
使用交易混合图方法应关注以下三点：
①系统日常业务主要有哪些操作，高峰期主要有哪些操作；
②数据库操作有多少；
③如果任务失败，则商业风险有多少。
选择重点交易的指标为高吞吐量、高数据库I/O、高商业风险。如表8-22所示，“登录”“生成订单”以及“发货”为负载压力测试重点。
表8-22 交易混合表
（3）用户概况图方法
使用用户概况图方法应关注以下两点：
①哪些任务是各用户都要执行的；
②针对各用户，不同任务的比例如何。
任务频率表如表8-23所示，负载压力测试需要模拟不同用户角色压力。
表8-23 任务频率表
四、测试案例制定
1．测试策略
一般包括对比测试环境和真实业务测试环境，真实业务操作环境又可能涉及局域网测试环境和机房测试环境等。
2．测试案例
一个局域网测试案例说明表如表8-24所示。
表8-24 局域网测试案例
3．测试内容
一般包括并发性能测试、疲劳强度测试、大数据量测试和系统资源监控等。
五、测试环境、工具、数据准备
1．测试环境准备
测试环境直接约束测试效果，测试环境不同，测试结果可能会有所不同，特别对于压力负载测试，因为压力负载测试结果往往是一组和时间有关的值，因此对负载压力测试环境的准备就显得特别的重要。
（1）测试环境的基本原则
①要满足软件运行的最低要求，不一定选择将要部署的环境；
②选用与被测系统相一致的操作系统和软件平台；
③营造相对独立的测试环境；
④无毒的环境。
（2）负载压力测试的测试环境
准备过程中可参考测试环境的基本准则，但又要考虑负载压力测试的特殊性和负载压力测试目的。负载压力测试一般强调“真实”应用环境下的性能表现，从而实现性能评估、故障定位以及性能优化的目的，故在负载压力测试环境的准备中要注意以下几点：
①如果是完全真实的应用运行环境，要尽可能降低测试对现有业务的影响；
②如果是建立近似的真实环境，要首先达到服务器、数据库以及中间件的真实，并且要具备一定的数据量，客户端可以次要考虑；
③必须考虑测试工具的硬件和软件配置要求；
④配置与业务相关联的测试环境需求；
⑤测试环境中应包括对交互操作的支持；
⑥测试环境中应该包括安装、备份及恢复过程。
（3）测试环境配置
①操作系统的版本（包括各种服务、安装及修改补丁）；
②网络软件的版本；
③传输协议；
④服务器及工作站机器；
⑤测试工具配置。
（4）良好的测试环境标准
①保证达到测试执行的技术需求；
②保证得到稳定的、可重复的、正确的测试结果。
2．测试工具准备
选择测试工具需要一定的原则，需要了解一些主流负载压力测试工具以及涉及到的测试工具的缺陷。
（1）负载压力测试工具选择
①步骤
a．进行负载压力性能测试首先应该选择一个合适的测试工具，一个测试工具能否满足测试需求、能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。该工具必须可模拟应用程序客户机。
b．具备基本功能后，可考虑工具的生产率。通常包含的分析工具越多，可记录的性能数据类型越多，可达到的生产率就越高，价格也就越高，不过有些低端负载测试程序是免费的。
②考虑事项
在选择测试工具时可考虑以下几点：
a．模拟客户机
首要要求一定是负载测试程序能够处理应用程序所使用的功能和协议。
b．运行多个模拟的客户机
运行多个模拟的客户机是负载测试程序最基本且最重要的功能，有助于确定哪些是负载测试程序和哪些不是。
c．脚本化执行并能编辑脚本
保证客户机与服务器之间交互的脚本可编辑，且小的改变不应该要求重新生成脚本。
d．支持会话
真正的负载压力测试工具必须支持会话或者cookies，并且不能对大多数J2EE应用程序进行负载测试。
e．可配置的用户数量
测试程序应该可以自主指定各脚本由多少个模拟用户运行，包括可以随时间自主改变模拟用户的数量，因为许多负载测试可做到从小的用户数量开始，并慢慢增加到更多的用户数量。
f．报告成功、错误和失败
各脚本都必须定义一个方法来识别成功的交互以及失败和错误模式（错误一般不会有页面返回，而失败可能在页面上得到错误的数据）。
g．页面显示
如果测试工具可以检查一些发送给模拟用户的页面，这会很有用，这样可以做到心中有数，以确保测试工作是正确的。
h．导出结果
可用不同的工具来分析测试结果，这些工具包括电子表格和可以处理数据的自定义脚本。虽然许多负载测试工具包括大量的分析功能，但是导出数据的能力使在以任意的方式分析和编辑数据方面具有更大的灵活性。
i．考虑时间
真实世界的用户不会在收到一页后立即请求另一页，一般在查看一页和下一页之间会有延迟。考虑时间该标准术语表示在脚本中加入延迟以更真实地模拟用户行为。大多数负载测试程序支持根据统计分布随机生成考虑时间。
j．客户机从列表中选择数据
用户一般不会使用同样的一组数据，每位用户通常与服务器进行不同的交互。模拟用户应该也这样做，如果在交互的关键点，脚本可从一组数据中选择数据，则可更容易地令模拟用户表现出使用不同数据的行为。
k．从手工执行的会话记录脚本
相对于编写脚本，用浏览器手工运行会话并记录该会话，然后再编辑会容易得多。
l．JavaScript
一些应用程序大量使用JavaScript并且需要模拟客户机支持。不过，使用客户端JavaScript可能会增加对测试系统上系统资源的需求。
m．分析工具
得到测试数据只是成功的一半，另一半是分析性能数据。因此测试工具提供的分析工具越多，就越有利于从不同的方面进行数据分析。
n．测量服务器端统计数字
基本负载压力测试工具测量客户机/服务器交互中基于客户机的响应时间。如果同时收集其他统计数据则更好，有了这些数据，就可进一步做一些类似查看服务器负载上下文中的客户机响应时间和吞吐量统计等有用的工作。
（2）负载压力测试工具的局限性
任何负载压力测试工具都不是完美无缺的，在实际使用中经常碰到一些问题，有以下几点：
①缺乏功能点的校验；
②对有些控件支持得不好；
③不能达到真实模拟负载；
④脚本的支持不够灵活；
⑤报错定位不够详细。
在实际压力测试中，为了达到测试目的，测试工程师要发挥最大的主观能动性来配合使用多种工具，达到最好的“性价比”。
（3）主流负载压力测试工具介绍
①OALoad——美国Compuware（康博）公司
特点如下：
a．测试接口
b．预测系统性能
c．通过重复测试寻找瓶颈问题
d．从控制中心管理全局负载测试
e．验证应用的可扩展性
f．快速创建仿真的负载测试
g．性能价格比较高
测试结果报告如图8-31所示。
图8-31 QALoad测试报告
测试结果分析如图8-32所示，1—2—3表示业务组A，4—5—6表示业务组B，7—8—9表示业务组C，10—11—12表示业务组D，在各个业务组中序号从小到大表示不同的并发用户。
图8-32 QALoad测试结果分析
②LoadRunner——美国MercuryInteractive公司。其特点如下：
a．测试接口：支持的协议多且个别协议支持的版本较高；
b．负载压力测试方案设置灵活；
c．丰富的资源监控，资源监控计数器，如图8-33所示；
d．报告可以导出到Word、Excel以及HTML格式。
图8-33 LoadRunner资源监控计数器
③BenchmarkFactorY——美国Quest软件公司
其特点如下：
a．可以测试服务器集群的性能；
b．可以实施基准测试；
c．可以生成高级脚本，例如脚本中数据池的生成可以采用随机数。
④WAS——美国Microsoft公司
WAS是一个Microsoft提供的免费的Web负载压力测试工具，应用比较广泛。介绍如下：
a．WAS简介
WAS可通过一台或多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器类型和Modem速度，它的功能和性能可以与数万美元的产品相媲美。
b．创建脚本
要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。可用以下方法创建脚本：
第一，通过记录浏览器的活动；
第二，通过导入IIS日志；
第三，通过把WAS指向Web网站的内容；
第四，手工制作。
c．客户端交易测试指标
第一，Number of hits：测试间隔内虚拟用户点击页面的总次数；
第二，Requests per second：每秒客户端的请求次数；
第三，Threads：线程数；
第四，TTFB Avg：从第一个请求发出到测试工具接收到服务器应答数据的第一个字节之间的平均时间；
第五，TTLB Avg：从第一个请求发出到测试工具接收到服务器应答数据的最后一个字节之间的平均时间；
准备好测试脚本之后，可以调整测试配置，以便观察不同条件下的应用性能。
d．WAS的设置界面
WAS的设置界面如图8-34所示。
图8-34 WAS的设置界面
第一，Stress Level和Stress Multiplier
这两项决定访问服务器的并发连接的数量。若要模拟的并发连接数量超过100个，可调整Stress multiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。
第二，Cookies
如果网站提供个性化服务，要进行身份验证或使用Cookies，还要为WAS提供一个用户目录。WAS中的用户存储了发送给服务器的密码以及服务器发送给客户端的Cookies。增加用户数量并不增加Web服务器的负载。必须提供足够数量的用户以满足并发连接的要求（Stress Level乘以Stress Multiplier）。
第三，warmup
WAS允许设置warmup（热身）时间，一般可设置为1分钟。在warmup期间WAS开始执行脚本，但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。
第四，限制带宽（throttle bandwidth）
设置页面提供的另一个有用的功能。带宽限制功能能够为测试模拟出Modem（14.4K，28.8K，56K）、ISDN（64K，128K）以及1T（1.54M）的速度。使用带宽限制功能可精确地预测出客户通过拨号网络或其他外部连接访问Web内服务器所感受的性能。
e．计数器
为理解上述不同的设置对应用的影响，有必要了解如何使用WAS收集性能数据。使用WAS，从远程Windows NT和Windows 2000机器获取和分析性能计数器（Performance Counter）很方便。加入计数器要用到如图8-35所示的Perf Counters分支。
图8-35 Perf Counters分析
在测试中选择哪些计数器显然跟测试目的有关。虽然以下清单不可能精确地隔离出性能瓶颈所在，但对一般的Web服务器性能测试来说却是一个好的开始。
第一，处理器：CPU使用百分比（% CPU Utilization）；
第二，线程：每秒的上下文切换次数（Context Switches Per Second（Total））；
第三，ASP：每秒请求数量（Requests Per Second）；
第四，ASP：请求执行时间（Request Execution Time）；
第五，ASP：请求等待时间（Request Wait Time）；
第六，ASP：置入队列的请求数量（Requests Queued）。
注意1：CPU使用百分比反映了处理器开销。CPU使用百分比持续地超过75%是处理器存在性能瓶颈的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于每秒数千次的上下文切换，说明忙于切换线程而不是处理ASP脚本。
注意2：每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。每秒的请求数量表示每秒内服务器成功处理的ASP请求数量。执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作出应答所需要的时间。
注意3：可以绘出测试中随并发用户数量的增加，每秒请求数量和反应时间的变化图。增加并发用户数量时每秒请求数量也会增加。然而，如果并发用户数量开始“压倒”服务器。如果继续增加并发用户数量，每秒请求数量开始下降，而反应时间则会增加。
注意4：置入队列的ASP请求数量也是一个重要的指标。如果在测试中该数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力，可能是因为在应用的中间层使用了一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。
注意5：运行WAS的客户机CPU使用率也有必要监视。如果这些机器上的CPU使用率持续地超过75%，说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。该情况下，测试客户机的数量必须增加，或者减小测试的StressLevel。
f．报表
每次测试运行结束后WAS会生成详细的报表，即使测试被提前停止。WAS报表可从View菜单选择Reports查看。以下为报表中几个重要的部分：
第一，如果是一个新创建的测试脚本，应该检查报表的ResultCodes部分。该部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了404代码（页面没有找到），说明在脚本中有错误的页面请求。
第二，页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后一个字节的平均时间（TTLB），以及测试脚本中各个页面的命中次数。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以毫秒计），TTLB包含了TTFB，是客户机接收到页面最后一个字节所需要的累计时间。
第三，报表中包含了所有性能计数器的信息。这些数据显示运行时各个项目的测量值，同时提供最大值、最小值、平均值等。报表实际提供的信息非常多。报表实例如图8-36所示。
图8-36 报表实例
⑤SILK PERFORMER V——美国Segue公司，其特点如下：
a．在工具中融合了功能测试的方法，即内容校验；
b．脚本采用PASCAL，资源消耗较小，支持一些底层访问；
c．错误可精确定位；
d．提供数据池模板，并可定制。
3．测试协议选择
测试工具中的“协议”指工具提供的测试接口，也可以理解为测试类型。
（1）LoadRunner提供的具有代表性的测试协议：
①应用程序解决方案：Citrix；
②Client/Server：MS SQL，ODBC，Oracle(2-tier)，DB2 CLI，Sybase Ctlib，Sybase Dblib，Windows Sockets及DNS；
③定制：C templates，Visual Basic templates，Java templates，JavaScript及VBScript；
④分布式组件：COM/DCOM，Corba-Java及Rmi-Java；
⑤E-business：FTP，LDAP，Palm，SOAP，Web（HTTP/HTML），及the dual Web/Winsocket；
⑥Enterprise Java Beans：EJB Testing及Rmi-Java；
⑦ERP/CRM：Baan，Oracle NCA，Peoplesoft-Tuxedo，Peoplesoft 8 Web multilingual，SAPGUI，SAP-Web，Siebel（Siebel-DB2CLI，Siebel-MSSQL，Siebel-Web及Siebel-Oracle）；
⑧Legacy：Terminal Emulation（RTE）；
⑨Mailing Services：Intemet Messaging（IMAP），MS Exchange（MAPI），POP3及SMTP；
⑩Middleware：Jacada及Tuxedo（6，7）；
⑪Streaming：MediaPlayer及RealPlayer；
⑫Wireless：i-Mode，VoiceXML及WAP。
（2）选择测试协议的策略
一个原则性的观点是“客户端与直接压力承受的服务器之间的通信协议是选择测试协议的唯一标准”。选择不同的协议决定了测试的成功与失败。利用测试工具提供的编程语言自己编写测试脚本是普遍认为最“惨”，最“酷”的方法，测试工具提供的使用比较广泛的测试脚本是C Script、JavaScript及VBScript。
4．测试数据准备
（1）概述
①简介
测试数据概念实施负载压力测试时，需运行系统相关业务，需要一些数据支持才可运行业务，这部分数据即为初始测试数据。例如ERP软件运行前财务账号的准备。测试数据的准备过程如下：
a．在初始的测试环境中需要输入一些适当的测试数据，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程领域时，有必要进行数据状态备份。制造初始数据即将合适的数据存储下来，需要时恢复，初始数据提供了一个基线用来评估测试执行的结果。
b．对系统实施负载压力测试时，经常会需要准备大数据量、实施独立的测试，或者与并发负载压力相结合的性能测试，这部分数据为业务测试数据。
c．在负载压力测试过程中，为模拟不同的虚拟用户的真实负载，需要将一部分业务数据参数化，这部分数据为参数化测试数据。
d．还需考虑特殊系统需要的测试数据，模拟真实环境测试，有些软件特别是面向大众的商品化软件，在测试时常常需要考察其在真实环境中的表现。
（2）准备测试数据的原因
①识别数据状态；
②验证测试案例；
③初始数据提供了一个基线用来评估测试执行的结果；
④业务数据提供负载压力背景；
⑤脚本中参数数据真实模拟负载。
5．自己动手编写测试工具
下面以两个案例为例，来介绍自己手动编写测试工具的思路：
（1）案例一：Web服务器通用性能测试系统的设计与实现
①概述
该系统不仅能够测试静态HTML页面的响应时间，而且能够模拟真实运行情况测试动态网页（包括ASP、PHP、JSP等）的响应时间，为服务器的性能优化和调整提供数据依据。
②两个问题
为了能够模拟大量用户同时访问Web动态页面的情况，必须要解决以下两个问题：
a．测试工具需要模拟出大量用户同时访问Web的情况；
b．测试工具需要模拟出单个用户访问Web时个性化的请求参数。
③构成部分
本性能测试系统主要由以下两部分构成：
a．性能测试数据文件
性能测试数据文件包含着用户访问Web的URL请求格式和大量用户访问系统的请求数据。
b．性能测试程序
实际测试中，性能测试程序将开设多个进程模拟大量用户对Web的访问，各进程从性能测试数据文件中随机地读出一组访问数据，然后发起对Web服务器的访问，等待Web服务器应答。测试结束后，性能测试程序将给出对于所有请求的平均系统响应时间。
由此，本性能测试工具能够真实地模拟大量用户同时访问Web的情况。
④系统结构
在实际运行的Web应用系统中，用户访问动态页面时传递的query字符串中的参数互不相同。为逼真地模拟实际情况，性能测试系统应在一段特定时间内，对待测页面同时发送多个请求，各请求的query参数互不相同，在发送的同时开始计时，直到收到系统的响应，计时停止，最后对所有请求的响应时间进行分析，就可得到系统性能的定量估计。系统结构如图8-37所示。
图8-37 系统结构示意图
实际系统由以下四部分组成：
a．模板文件
第一，简介
模板文件为纯文本文件，包含单个用户访问Web发送的URL，每行格式如下：
GET(POST)http://host:port/path/filename?xxx=@1@&@2@
其中，GE或者POST表示参数传递的方式。query字符串中的@是本系统特设字符，表示@及其后面的数字需要被数据文件中对应的参数数据所取代。两个@之间为参数序号，只能为数字，在整个模板文件中相同的参数序号代表相同的参数。
第二，模板数据结构定义
模板文件中的请求格式在程序开始时读入模板数据结构中，模板数据结构定义如下：
b．数据文件
数据文件是用户访问动态页面时传递的query参数集合，为纯文本文件，参数数据与模板文件中@号及其后面的数字相对应，之间用空格隔开，每组一行。
c．性能测试程序
第一，简介
测试Web应用系统时，性能测试程序将开设c个进程，各进程可串行地开设n个会话，各会话模拟一个真实用户，按照模板文件中提供的访问Web系统的格式，从数据文件中读取一组query参数，然后对Web系统发起请求；与此同时，程序开始计时，直到收到系统的响应，计时停止，系统统计接收的字节数，将结果写入结果文件，本次会话结束，这个进程开始一个新的会话，如此循环n次。测试结束后，给出系统的综合性能评估。
由上可知，本系统发送请求的并发度是c，即在测试的时间段内，对Web应用系统同时发送的请求有c个，本系统发送请求的串行度为n，一共可以模拟c×n个用户对系统的访问。
第二，流程图
性能测试程序流程如图8-38所示。在图8-38中，性能测试程序fork出c个进程，各进程都开设一个Socket，通过Socket向Web服务器发送请求。为了使测试程序能够快速地向服务器发送请求，程序一开始就将数据文件中的所有数据读入内存，数据使用一个二维数组存放。
图8-38 主程序流程
d．结果处理程序
测试程序运行结束后，生成的结果文件包含着Web服务器对各请求的响应时间，还包含各请求返回的字节数。结果文件由结果处理程序处理，计算出Web服务器对所有请求的平均响应时间。
（2）案例二：通用应用系统性能评测环境设计
①概述
LoadRunner通过运行脚本模拟的方法的评估结果是有一定的缺陷的，需要一种适用于特定应用的运行模拟和性能评测方法与支撑环境，来对应用系统的实际性能评测提供有效支持。此处提出的通用应用系统性能评测环境，是通过并行执行分布于不同客户机上的多种类型的实际应用程序代码，模拟一个应用系统在多个客户端并发访问情况下的实际运行情况，同时对应用程序代码的执行状态和结果等信息进行记录进行；在模拟执行完成后，对执行记录进行分析，给出被测系统的性能指标。
②应用系统性能评测环境的组成
应用系统性能评测环境主要由应用逻辑运行模拟代理、模拟控制中心、数据搜集器和统计分析工具等部分组成，其系统结构如图8-39所示。
图8-39 系统结构图
其中，应用逻辑运行模拟代理负责驱动执行被测系统的应用逻辑代码，并记录每次执行的状态和性能相关信息；模拟控制中心控制整个性能评测过程中的所有运行模拟代理；数据搜集器负责在测量完成之后，接收来自运行模拟代理的性能测量数据；统计分析工具负责对测量获得的性能相关数据进行分析，从而得出被测系统的相关性能数据。
在评测过程中，运行模拟代理与控制中心之间通过基于对象传输的专用网络通信接口进行通信。由于应用系统的实际运行环境各异，评测系统被设计成能够运行在多种操作系统平台上。所有其他组件的下层是操作系统相关调用抽象层，对于不同操作系统平台，需要实现相应的实际处理对象。
③需解决的问题
由于目的是通过模拟真实的并发环境来获取系统的实际性能，在设计与实现上需要充分考虑以下问题，并加以解决：
a．系统实际处理代码的嵌入方式的应用和响应时间的测定；
b．控制中心对运行模拟代理的有效控制；
c．多操作系统平台支持与评测系统本身的执行效率；
d．可扩展性。
6．准备过程中与用户交流
做为第三方测试机构，在负载压力测试准备的过程中，经常需要与用户交流，交流的内容如下：
（1）系统的运行模式；
（2）系统运行的硬件环境和软件环境，包括客户端、中间件、Web服务器、应用服务器、数据库服务器等；
（3）系统网络架构；
（4）系统主要功能模块以及主要功能需求；
（5）系统主要性能需求，例如并发、疲劳、大数量等；
（6）系统未来发展功能需求和性能需求；
（7）系统网络容量规划等。
六、测试脚本录制、编写与调试
1．测试脚本
测试脚本指Vuser脚本，即虚拟用户回放所使用的脚本。脚本的产生可以采用录制、编写或者录制加编写混合模式，初始生成的脚本经过增强编辑之后，必须再经调试才可用。Vuser脚本的结构和内容因Vuser类型的不同而不同。开发Vuser脚本的过程如图8-40所示。
图8-40 开发Vuser脚本的过程
2．录制脚本
（1）简介
一般测试过程中，录制脚本所占比例较大。测试工具提供了大量录制Vuser脚本的工具，且可通过将控制流结构和其他测试工具的API添加到脚本中来增强该基本脚本。然后，配置运行时设置。运行时设置包括迭代、日志和计时信息以及定义Vuser在执行Vuser脚本时的行为。要验证脚本是否能正确运行，应以单独模式运行该脚本。
（2）录制的内容
主要录制用户在客户端应用程序中执行的典型业务流程。测试工具通过录制客户端和服务器之间的活动来创建脚本。
①录制活动创建脚本
如图8-41所示。
图8-41 录制活动创建脚本
②API调用生成脚本
用VuGen创建各Vuser脚本都可通过执行对服务器API调用来直接与服务器通信，而不需依赖客户端软件。故可使用Vuser来检查服务器性能。为API调用生成脚本如图8-42所示。
图8-42 API调用生成脚本
Vuser与服务器直接通信时，不需在用户界面中耗费系统资源，就可在一个工作站中同时运行大量Vuser，进而可使用很少的测试计算机来模拟非常大的服务器负载。测试工具都留有手工编写脚本入口，且提供相应测试类型API，测试人员在此环境下可编写生成脚本。
3．脚本调试注意的问题
对于C/S结构的脚本，在数据量大时，脚本非常庞大。对于该脚本的调试，应注意以下方面：
（1）动态数据的处理
经常会碰到某个表单的编号记录在另一个表中的情况，程序通过查询该表，并加1的方式获取到该编号。对于该问题，可以分解为以下3步（以ORACLE数据库为例）：
①获取数据，可使用lrd_ora8_save_col函数；
②函数值加1处理，可使用lr_param_increment函数；
③替换处理，即把Update中的具体值替换为我们获取并处理好的参数就可以了。
（2）参数化过程
所关注的是Insert及Update语句。将这些语句中违反数据库约束的地方进行参数化，且仅关注这些语句，理清关系和整个程序的流程，作参数时直接ReplaceAll即可。
七、场景制定
1．创建Vuser组
方案由Vuser组构成，Vuser模拟与应用程序进行交互的实际用户。运行方案时，Vuser会在服务器上生成负载，测试工具会监视服务器和事务性能。Vuser组用于将方案中的Vuser组织成可管理的组。可以创建包含具有共享或相似特征的Vuser组。
2．配置Vuser组中的Vuser
可以为定义的Vuser组中的各Vuser定义属性。对于各Vuser，可以分配不同的脚本和负载生成器计算机。
3．配置Vuser运行时的设置
可以设置脚本运行时的设置，采用在控制中心自定义执行Vuser脚本的方式。
4．配置负载生成器
（1）简介
测试执行前，需要配置方案的负载生成器和Vuser行为，即制定场景。LoadRunner允许修改这些设置以便自定义方案行为，这些设置适用于所有未来的方案运行并且通常只需设置一次。该类设置适用于方案中所有的负载生成器。如果全局方案设置与单个负载生成器的设置不同，则负载生成器设置进行替代。
（2）注意
①可以指出哪些负载生成器将在方案中运行Vuser。如果要隔离特定计算机以测试其性能，则禁用负载生成器相当有用；
②可以为各负载生成器配置附加设置。可配置的设置有：状态、运行时文件存储、UNIX环境、运行时配额、Vuser状态、Vuser限制、连接日志（专家模式）、防火墙和WAN仿真。
5．配置终端服务设置
（1）终端服务管理器
可使用终端服务管理器，来远程管理在终端服务器上的、负载测试方案中运行的多个负载管理器。可使用终端服务器克服只能在基于Windows的负载生成器上运行单个GUI Vuser的局限性。
（2）终端服务客户端
①简介
使用终端服务器客户端，可通过远程计算机在基于服务器的计算环境中操作。终端服务器通过网络传送应用程序，并通过终端仿真软件显示。服务器操作系统以透明的方式将该会话独立于其他任何客户端会话进行管理。检查如图8-43所示的测试工具组件协同工作可以了解测试工具组件在终端会话期间如何协同工作。测试工具组件协同工作示意图如图8-43所示。
图8-43 测试工具组件协同工作
②功能
终端服务器客户端可同时运行多个终端会话。使用终端服务管理器，可选择要在方案中使用的终端数量以及各终端可以运行的最大Vuser数。这样，终端服务管理器便可在客户端会话间均匀地分配虚拟用户的数量。使用终端服务管理器可以做到以下几点：
a．在负载生成器计算机上设置终端服务器代理；
b．在控制中心计算机上启动终端客户端会话；
c．使用终端服务管理器在终端服务器上分配Vuser。
6．配置WAN仿真设置
使用配置WAN仿真设置的好处：
（1）可以在部署前模拟并测试广域网（WAN）对最终用户响应时间和性能的影响；
（2）可以在测试环境中准确地测试实际网络条件下WAN部署产品的点到点的性能；
（3）通过引入极为可能发生的WAN影响，可以描绘WAN云图的许多特征，并在单一网络环境中有效地控制仿真；
（4）可以在WAN仿真监视报告中观察仿真设置对网络性能的影响。
7．配置脚本
为Vuser或Vuser组选择脚本后，可以编辑脚本或查看所选脚本的详细信息。
八、测试执行
1．运行场景
（1）场景执行期间完成的工作
运行场景时，会为Vuser组分配负载生成器并执行其Vuser脚本。在场景执行期间，将要完成以下工作：
①记录在Vuser脚本中定义的事务的持续时间；
②执行包括在Vuser脚本中的集合；
③收集Vuser生成的错误、警告和通知消息。
（2）运行场景的过程
可以在无人干预时运行整个场景，或者可交互地选择要运行的Vuser组和Vuser。
场景开始运行时，Controller会首先检查场景配置信息。接着，将调用已选定与该场景一起运行的应用程序。然后，会将各Vuser脚本分配给其指定的负载生成器。Vuser组就绪后，将开始执行其脚本。
场景运行时，可监视各Vuser，查看由Vuser生成的错误、警告和通知消息，以及停止Vuser组和各个Vuser。可允许单个Vuser或组中Vuser在停止前完成正在运行的迭代，在停止前完成正在运行的操作或者立即停止运行，还可在场景运行时激活其他Vuser。下面情况，场景将结束：所有Vuser已完成其脚本，持续时间用完或者终止场景。以下为运行场景的过程：
①打开现有场景或新建一个场景；
②配置并计划场景；
③设置结果目录；
④运行并监视场景。
2．在执行期间查看Vuser
可以在场景执行期间查看Vuser的活动：
（1）在Controller负载生成器计算机中，可以查看输出窗口，联机监视Vuser性能以及查看执行场景的Vuser的状态。
（2）在远程计算机中，可以查看包含活动Vuser的有关信息的代理摘要。
3．监视场景
工具通常提供以下联机监视器：
（1）“运行时”监视器
“运行时”监视器显示参与场景的Vuser的数目和状态，以及Vuser所生成的错误数量和类型。还提供用户定义的数据点图，其中显示Vuser脚本中的用户定义点的实时值。
（2）“事务”监视器
“事务”监视器显示场景执行期间的事务速率和响应时间。
（3）“Web资源”监视器
“Web资源”监视器用于度量场景运行期间Web服务器上的统计信息。提供关于场景运行期间的Web连接、吞吐量、HTTP响应、服务器重试和下载页的数据。
（4）“系统资源”监视器
“系统资源”监视器测量场景运行期间使用的Windows、UNIX、TUXEDO、SNMP和Antara Flame Thrower资源。
（5）“网络延迟”监视器
“网络延迟”监视器显示关于系统上的网络延迟的信息。要激活网络延迟监视器，必须在运行场景之前设置要监视的网络路径。
（6）“防火墙”监视器
“防火墙”监视器用于度量场景运行期间防火墙服务器上的统计信息。
（7）“Web服务器资源”监视器
“Web服务器资源”监视器用于度量场景运行期间Apache、Microsoft IIS、iPlanet（SNMP）和iPlanet/NetscapeWeb服务器上的统计信息。
（8）“Web应用程序服务器资源”监视器
“Web应用程序服务器资源”监视器用于度量场景运行期间Web应用程序服务器上的统计信息。
（9）“数据库服务器资源”监视器
“数据库服务器资源”监视器用于度量与SQL Server、Oracle、Sybase和DB2数据库有关的统计信息。
（10）“流媒体”监视器
“流媒体”监视器用于度量Windows Media服务器、RealPlayer音频/视频服务器及RealPlayer客户端上的统计信息。
（11）“ERP/CRM服务器资源”监视器
“ERP/CRM服务器资源”监视器用于度量场景运行期间SAPR/3系统服务器、SAP Portal、Siebel Web服务器和Siebel Server Manager服务器的统计信息。
（12）“Java性能”监视器
“Java性能”监视器用于度量Java 2 Platform，Enterprise Edition（J2EE）对象及使用J2EE和EJB服务器计算机的Enterprise Java Bean（EJB）对象的统计信息。
（13）“应用程序部署解决场景”监视器
“应用程序部署解决场景”监视器用于度量场景运行期间Citrix MetaFrame XP和1.8服务器的统计信息。
（14）“中间件性能”监视器
“中间件性能”监视器用于度量场景运行期间TUXEDO和IBM WebSphere MQ服务器上的统计信息。
（5）远程性能监视器
所有的监视器所收集数据都可生成该监视器的图。有些工具也提供远程性能监控。在负载测试运行过程中，远程性能监视器可以查看特定的图，这些图显示Vuser在服务器上生成的负载的信息。用户在连接到Web服务器的Web浏览器上查看负载测试数据。利用远程性能监视器查看负载测试数据如图8-44所示。
图8-44 利用远程性能监视器查看负载测试数据
其中系统资源、网络延迟、防火墙、Web服务器资源、Web应用程序服务器资源、数据库服务器资源、ERP/CRM服务器资源、应用程序部署解决场景、中间件性能监视器，如果需要对这些监视器进行激活，必须在运行场景之前设置要监视的资源列表和选项。
远程性能监视器服务器包含一个用ASP页面实现的网站，以及一个包含负载测试图的文件服务器。与Controller联机组件进行交互，并按相应的许可证处理同时查看负载测试的用户数。
九、获取测试结果
场景执行期间，Vuser会在执行事务的同时生成结果数据。要在测试执行期间监视场景性能，可使用联机监视工具。要查看测试执行之后的结果摘要，可使用下列一个或多个工具：
1．“Vuser日志文件”
“Vuser日志文件”包含对各Vuser运行的场景的完整跟踪。这些文件位于方案结果目录中。
2．“Controller输出”窗口
“Controller输出”窗口显示有关场景运行的信息。如果场景运行失败，可以在该窗口中查找调试信息。
3．“Analysis图”
“Analysis图”有助于确定系统性能并提供有关事务和Vuser的信息。通过合并几个场景的结果或者将几个图合并成一个图，可以对多个图进行比较。
4．“图数据”视图和“原始数据”视图
“图数据”视图和“原始数据”视图以电子表格格式显示用于生成图的实际数据。可以将这些数据复制到外部电子表格应用程序中，以进行进一步处理。
5．“报告”
“报告”实用程序允许查看每个图的摘要HTML报告或各种性能和活动报告。可以将报告创建成Microsoft Word文档，会自动以图形或表格形式总结和显示测试的重要数据。
工具的结果分析功能是有限的，要定位问题测试，工程师的经验和智慧起到很大作用。
十、结果评估与测试报告
1．交易处理性能评估指标
（1）并发用户数
并发用户数是负载压力测试的主要指标，体现了系统能够承受的并发性能。以下为两类并发用户数指标：
①系统最佳性能的并发用户数；
②系统能够承受的最大并发用户数。
这两类指标在某种情况下有可能重叠。
（2）交易响应时间
该指标描述交易执行的快慢程度，是用户最直接感受到的系统性能，也是故障定位迫切需要解决的问题。
（3）交易通过率
交易通过率指每秒钟能够成功执行的交易数，描述系统能够提供的“产量”，用户可以此来评估系统的性能价格比。
（4）吞吐量
吞吐量指每秒通过的字节数，以及通过的总字节数。此指标在很大程度上影响了系统交易的响应时间，形成响应时间的“拐点”。
（5）点击率
描述系统响应请求的快慢。
2．资源占用性能评估
（1）服务器操作系统资源占用
资源占用主要涉及服务器操作系统资源占用、数据库资源占用、中间件资源占用等内容，具体介绍如下：
①服务器操作系统资源占用监控指标
通过《负载压力测试指标》章节，可将服务器操作系统资源占用监控指标概括如下：
a．CPU；
b．磁盘管理；
c．内存；
d．交换区SWAP；
e．进程；
f．安全控制；
g．文件系统。
②对某些指标的举例分析
a．Memory
内存使用情况可能是系统性能中最重要的因素。页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从RAM移动到磁盘的过程，以释放内存空间。频繁的页交换将降低系统性能。要监视内存不足的状况，从以下的对象计数器开始：
第一，Available Mbytes
可用物理内存数。如果Available Mbytes的值很小，则说明计算机上总的内存可能不足或某程序没有释放内存。
第二，pages/sec
表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放内存空间的页面数。一般如果pages/sec持续高于几百，则应进一步研究页交换活动。有可能需要增加内存，以减少换页的需求。pages/sec的值很大，可能是运行使用内存映射文件的程序所致。
第三，pageread/sec
页的硬故障，page/sec的子集，为解析对內存的引用，必须读取页文件的次数。阈值>5，越低越好。大数值表示磁盘读而不是缓存读。
b．磁盘使用情况计数器和内存计数器
由于过多的页交换要使用大量的硬盘空间，有可能导致页交换内存不足与页交换的磁盘瓶颈混淆。故在研究内存不足不太明显的页交换的原因时，必须跟踪如下的磁盘使用情况计数器和内存计数器：
第一，Physical Disk \% Disk Time；
第二，Physical Disk \Avg.Disk Queue Length
如果页面读取操作速率很低，同时%Disk Time和Avg.Disk Queue Length的值很高，则可能有磁盘瓶颈。如果队列长度增加的同时页面读取速率并未降低，则内存不足。要确定过多的页交换对磁盘活动的影响，需要将Physical Disk\Avg，Disksec/Transfer和Memory\pages/sec计数器的值增大数倍。如果计数结果超过了0.1，则页交换将花费10%以上的磁盘访问时间。如果长时间发生该情况，则可能需要更多的内存。
第三，Page Faults/sec
每秒钟软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取），而page/sec只表明数据不能在指定内存中立即使用。
第四，Cache Bytes
文件系统缓存（File System Cache），通常为50%的可用物理内存。如果怀疑内存泄露，监视Memory\Available Bytes和Memory\Committed Bytes，观察内存行为，并监视可能泄露内存进程Process\Private Bytes、Process\Working Set和Process\Handle Count。如果怀疑内核模式进程导致泄露，则还应监视Memory\Pool Nonpaged Bytes、Memory\Pool Nonpaged Allocs和Process(process＿Name)\Pool Nonpaged Bytes。
第五，Pages per second
每秒钟检索的页数。该数字应少于每秒1页。
第六，Page Faults/sec
将进程产生的页故障与系统产生的相比较，以判断该进程对系统页故障产生的影响。
第七，Work set
处理线程最近使用的内存页，反映各进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在内存中。当自由內存少于一个特定的阈值时，页就会被清除出内存。
第八，Inetinfo
Private Bytes。此进程所分配的无法与其他进程共享的当前字节数量。如果系统性能随着时间降低，则此计数器可以是内存泄漏的最佳指示器。
第九，Processor
监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助决定是否存在瓶颈。
第十，%Processor Time
%Processor Time被处理器消耗的处理器时间数量。如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
第十一，% User Time
% User Time表示耗费CPU的数据库操作。如果该值很高，可考虑增加索引，尽量使用简单的表联接、水平分割大表格等方法来降低该值。
第十二，% Privileged Time
% Privileged Time（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和“Physical Disk”参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置“Tempdb in RAM”，减低“max asyncI/O”“max lazy writerI/O”等措施会降低该值。跟踪计算机的服务器工作队列，当前长度的Server Work Queues\Queue Length计数器会显示出处理器瓶颈。队列长度持续大于4，则表示可能出现处理器拥塞。此计数器不是一段时间的平均值，是特定时间的值。
第十三，% DPC Time
% DPC Time越低越好。在多处理器系统中，如果该值大于50%，并且“Processor：%Processor Time”非常高，加入一个网卡可能会提高性能，提供的网络已不饱和。
第十四，Context Switches/sec
如果决定要增加线程字节池的大小，应该同时监视实例化inetinfo和dllhost进程这两个计数器。增加线程数可能会增加上下文切换次数，这样性能不会上升，反而下降。如果多个实例的上下文切换值非常高，就应减小线程字节池的大小。
第十五，% Disk Time
% Disk Time指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果只有%Disk：Time比较大，而CPU和内存都比较适中，硬盘可能会是瓶颈。
第十六，Avg.Disk Queue Length
Avg.Disk Queue Length指读取和写入请求（为所选磁盘在实例间隔中列队）的平均数。该值应不超过磁盘数的1.5～2倍。要提高性能，可增加磁盘。注意，一个Raid Disk实际有多个磁盘。
第十七，Average Disk Read/Write Queue Length
Average Disk Read/Write Queue Length指读取（写入）请求（列队）的平均数。
第十八，Disk Reads(Writes)/s
物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大允许读取次数。
第十九，Average Disksec/Read
Average Disksec/Read指以秒计算的在此盘上读取数据的所需平均时间。
第二十，Average Disksec/Transfer
Average Disksec/Transfer指以秒计算的在此盘上写入数据的所需平均时间。
第二十一，BytesT otal/sec
BytesT otal/sec为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽进行比较。
（2）数据库资源占用监控指标
①内容
通过《负载压力测试指标》章节的讨论，可将数据库资源占用监控指标概括如下：
a．读写页面的使用情况；
b．超出共享内存缓冲区的操作数；
c．上一轮询期间作业等待缓沖区的时间；
d．共享内存中物理日志和逻辑日志的缓冲区的使用率；
e．用户事务或者表空间事务；
f．数据库锁资源；
g．关键业务的数据表的表空间增长；
h．SQL执行情况；
i．磁盘的数据块使用情况以及被频繁读写的热点区域。
②举例分析
以SQL Server数据库性能计数器为例分析。
a．Access Methods
用于监视数据库逻辑页访问方法。
b．Full Scans/sec
每秒钟不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果该计数器显示的值比1或2高，应该分析查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
c．Page splits/sec
由于数据更新操作引起的每秒页分割的数量。
d．Buffer Manager
监视SQL Server如何使用内存存储数据页、内部数据结构和过程高速缓存。计数器在SQL Server从磁盘读取数据库页和将数据库页写入磁盘时监视物理I/O。监视SQL Server所使用的内存和计数器，有助于确定是否由于缺少可用物理内存存储高速缓存中经常访问的数据，而导致瓶颈存在。SQL Server必须从磁盘检索数据，以及考虑是否可通过添加更多内存，或使更多内存可用于数据高速缓存或SQL Server内部结构来提高查询性能。
e．Disk I/O
SQL Server从磁盘读取数据的频率，尽可能减少物理I/O可以提高查询性能。
f．Page Reads/sec
每秒物理数据库读的页数。该统计信息显示的是在所有数据库间的物理页读取总数。由于物理I/O的开销大，可通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减至0最小。
g．Page Writes/sec
每秒物理数据库写的页数。
h．Buffer Cache Hit Ratio
在“缓冲池”（Buffer Cache/Buffer P001）中没有被读过的页占整个缓冲池中所有页的比率，可在高速缓存中找到。该比率是高速缓存命中总数除以自SQL Server实例启动后对高速缓存的查找总数。经过很长时间后，该比率的变化很小。可以通过增加SQLServer可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定，但比率最好为90%或更高。增加内存直到该数值持续高于90%，表示90%以上的数据请求可以从数据缓冲区中获得所需数据。
i．Lazy Writes/sec
惰性写进程每秒写的缓冲区的数量。其值最好为0。
j．Cache Manager
对象提供计数器，用于监视SQLServer如何使用内存存储对象。
k．Cache Hit Ratio
Cache可以包括Log Cache，Buffer Cache以及Procedure Cache，是一个总体的比率，是高速缓存命中次数和查找次数的比率之和。其对查看SQLServer高速缓存对于系统性能提升非常有效，是非常好的计数器。如果该值持续低于80%，就需增加更多的内存。
l．Latches
用于监视称为“闩锁”的内部SQL Server资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。
m．Average Latch Wait Time(ms)
一个SQL Server线程必须等待一个闩的平均时间，以毫秒为单位。如果该值很高，系统可能正经历严重的竞争问题。
n．Latch Waits/sec
在闩上每秒的等待数量。如果该值很高，表明系统正经历严重的竞争问题。
o．Locks
提供有关个别资源类型上的SQLServer锁的信息。锁加在SQLServer资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。可以同时监视Locks对象的多个实例，各实例代表一个资源类型上的一个锁。
p．Number of Dead locks/sec
导致死锁的锁请求的数量。
q．Average Wait Time(ms)
线程等待某种类型的锁的平均等待时间。
r．Lock Requests/sec
每秒钟某种类型的锁请求的数量。
s．Memory manager
Memory manager用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视SQL Server实例所使用的内存，有助于确定是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈的存在。SQL Server必须从磁盘检索数据，考虑是否可通过添加更多内存，或使更多内存用于数据高速缓存或SQL Server内部结构，来提高查询性能。
t．Lockblocks
服务器上锁定块的数量，锁是加在页、行或表这样的资源上。
u．Total Server Memory
SQL Server服务器当前正在使用的动态内存总量。
（3）中间件资源占用监控
①中间件包括：
a．Web中间件；
b．应用中间件；
c．交易中间件；
d．其他中间件。
②举例分析
以IIS为例来分析。
a．% File Cache Hits
全部缓存请求中缓存命中次数所占的比例，反映IIS的文件缓存设置的工作情况。对于一由大部分静态网页组成的网站，该值应该保持在80%左右。
File Cache Hits是文件缓存命中的具体值，而File Cache Flushes是自服务器启动之后文件缓存刷新次数，如果刷新得太慢，会浪费内存；如果刷新得太快，频繁的丢弃生产会起不到缓存的作用。通过比较File Cache Hits和File Cache Flushes可得出缓存命中率与缓存清空率的比率。通过观察这两个值，可以得到一个适当的刷新值。
b．Web Service部分
第一，Bytes Total/sec：显示Web服务器发送和接收的总字节数。低数值表明该IIS正在以较低的速度进行数据传输；
第二，Connection Refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈；
第三，Not Found Errors：显示由于被请求文件无法找到而导致的服务器无法回应的请求数（HTTP状态代码404）。
3．故障分析
（1）故障分析重点内容：
①CPU问题；
②内存和高速缓存；
③磁盘（I/O）资源问题；
④配置参数；
⑤应用系统网络设置；
⑥数据库服务器故障定位。
（2）经验探讨
①经验举例1
交易的响应时间如果很长，远远超过系统性能的需求，表示耗费CPU的数据库操作，可考虑是否有索引以及索引建立得是否合理。尽量使用简单的表链接、水平分割大表格等方法来降低该值。
②经验举例2
测试工具可模拟不同的虚拟用户来单独访问Web服务器、应用服务器和数据库服务器，就可在Web端测出的响应时间减去以上各分段测出的时间，可知道瓶颈在哪里并着手调优。
③经验举例3
UNIX资源监控（NT操作系统同理）中指标内存页交换速率（Pagingrate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈，也可能是内存访问命中率低。
④经验举例4
UNIX资源监控（NT操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可考虑增加一个处理器或换一个更快的处理器。合理使用的范围在60%～70%。
⑤经验举例5
Tuxedo资源监控中指标队列中的字节数（Bytes on queue），队列长度应不超过磁盘数的1.5～2倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
⑥经验举例6
SQL Server资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。注意该参数值是从SQL Server启动后，就一直累加记数，故运行经过一段时间后，该值将不能反映系统当前值。
（3）优化调整设置
针对上述故障分析的重点内容，需做相应的优化调整，建议如下：
①CPU问题
a．考虑使用更高级的CPU代替目前的CPU；
b．对于多CPU，考虑CPU之间的负载分配；
c．考虑在其他体系上设计系统，例如增加前置机、设置并行服务器等。
②内存和高速缓存
a．内存的优化包括操作系统、数据库、应用程序的内存优化；
b．过多的分页与交换可能降低系统的性能；
c．内存分配也是影响系统性能的主要原因；
d．保证保留列表具有较大的邻接内存块；
e．调整数据块缓冲区大小（用数据块的个数表示）是一个重要内容；
f．将最频繁使用的数据保存在存储区中。
③磁盘（I/O）资源问题
a．磁盘读写进度对数据库系统是至关重要的，数据库对象在物理设备上的合理分布能改善性能；
b．磁盘镜像会减慢磁盘写的速度；
c．通过把日志和数据库对象分布在独立的设备上，可以提高系统的性能；
d．把不同的数据库放在不同的硬盘上，可以提高读写速度。建议把数据库、回滚段、日志放在不同的设备上。
e．把表放在一块硬盘上，把非簇的索引放在另一块硬盘上，保证物理读写更快。
④调整配置参数
a．包括操作系统和数据库的参数配置；
b．并行操作资源限制的参数（并发用户的数目、会话数）；
c．影响资源开销的参数；
d．与I/O有关的参数。
⑤优化应用系统网络设置
a．可以通过数组接口来减少网络呼叫，不是一次提取一行，而是在单个往来往返中提取10行，这样做效率较高；
b．调整会话数据单元的缓冲区大小；
c．共享服务进程比专用服务进程提供更好的性能。
（4）负载压力典型问题分析
负载压力测试需要识别的故障问题主要包括：
①非正确执行的处理；
②速度瓶颈与延迟；
③不能达到满意服务水平；
④接口页面不能正确地装载或者根本不能装载。
当在合理的加载下出现这些类型的问题时，表示可能有基础性的设计问题。
（5）Web网站故障分析举例
①问题分析
目前Web开发者开始提供可定制的Web网站，像搜索数据之类的任务，现在可以由服务器执行，而无需客户干预。然而，这些变革导致许多网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。可以使用以下方法来解决这些问题：
a．优化ASP代码；
b．优化数据库调用；
c．使用存储过程；
d．调整服务器性能。
与静态页面的速度相比，任何数据库调用都会显著地影响Web网站的响应速度。
②性能优化方案
此处提出的性能优化方案基于的事实为：访问静态HTML页面要比访问那些内容依赖于数据库调用的页面要快。其基本思想为：在用户访问页面前，预先从数据库提取信息，写入存储在服务器上的静态HTML页面。为保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的生成。该方案并不能够适应所有的情形。
③处理频繁变动数据的方法
a．每当该页面被调用时，脚本就会提取最后的更新时间并将它与当前时间比较。如果每次访问ASP页面的时候都要提供最新的信息，或者输出与用户输入密切相关，这种方法并不实用，但可以适应以固定的时间间隔更新信息的场合。
如果数据库内容由客户通过适当的ASP页面更新，要确保静态页面也能够自动反映数据的变化，可以在ASP页面中调用Update脚本。这样，每当数据库内容改变时，服务器上也有了最新的静态HTML页面。
b．借助Web助手向导，该向导能够利用Transact-SQL、存储过程等从SQL Server数据生成标准的HTML文件。Web助手向导能够用来定期地生成HTML页面，它可以通过触发子更新HTML页面。SQL Server使用名为sp_makewebtask的存储过程创建HTML页面，它的参数是目标HTML文件的名字和待执行存储过程的名字，查询的输出发送到HTML页面上。另外，也可以选择使用可供结果数据插入的模板文件。用户访问页面的时候正好在执行更新，可以利用锁或者其他类似的机制把页面延迟几秒钟。
④测试结果
对纯HTML加调度ASP代码和普通的ASP文件进行性能测试。普通ASP文件要查找5个不同的表，为页面提取数据。为和这两个文件相比较，对一个只访问单个表的ASP页面和一个纯HTML文件也进行了测试。测试结果如表8-25所示。
表8-25 加调度ASP代码和普通ASP代码测试对比
其中TTFB是指“Total Time to First Byte”，TTLB是指“Total Time to Last Byte”。测试结果显示，访问单个表的ASP页面的处理时间是720.5ms，而纯HTML文件则为427ms。普通的ASP文件和纯HTML加调度ASP代码的输出时间相同，但处理时间有了2019.61的差距，即在该测试环境下，可把处理速度提高43%。
需要注意以下几点：
a．如果要让页面每隔一定的访问次数进行更新，如100次，则这第100个用户就必须等待新的HTML页面生成；
b．静态页面方法并不能够适合所有类型的页面，某些页面在进行任何处理之前必须要有用户输入，但是，该方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面，而且该情况下其将发挥出更大的效率；
c．大多数情况下，动态页面的生成将在相当大的程度上提高网站的性能，且无需在功能上有所折衷。
4．数据库服务器性能问题及原因分析
数据库服务器性能问题主要表现在某些类型操作的响应时间过长、同类型事务的并发处理能力差和锁冲突频繁发生等方面，即这些问题是数据库服务器性能不佳的典型表现。以下分情况加以分析：
（1）单一类型事务响应时间过长
响应时间是系统完成事务执行准备后所采集的时间戳和系统完成待执行事务后所采集的时间戳之间的时间间隔，是衡量特定类型应用事务性能的重要指标，标志用户执行一项操作大致需要多长时间。
响应时间过长意味着用户完成执行一项命令需要等待相当长的时间。通常用户能够接受的响应时间最大为200ms，响应时间过长也是造成系统锁冲突严重的重要原因。造成响应时间过长的原因可以从以下几个方面考虑：
①数据库服务器负载过重
a．主要表现
标志着当前服务器系统的硬件条件不能满足实际用户对性能的需要，主要表现在CPU使用率高、内存占用率大、I/O与页面交换频繁发生等方面。由于服务器系统本身一般都提供性能监控程序，定位服务器性能问题相对容易。
b．解决方法
解决这类问题的方法是升级服务器硬件，提高数据库服务器本身的处理能力。但通对于某些诸如算法复杂度过高等问题根本无法解决。
②糟糕的数据库设计
糟糕的数据库设计是导致单一事务响应时间过长最重要的原因。在数据库设计方面，对响应时间影响较大的因素如下：
a．索引的使用
索引的使用将极大影响事务执行的响应时间。应用程序在访问大规模数据库表时没有使用索引。
注意：对组合索引进行查询时，查询条件中字段的顺序与数据库设计的索引字段顺序要一致。此外，并非增加索引就一定能够提高单一事务执行的响应时间。避免过多的索引使用极大地增加插入操作的花费。
b．数据库表规模
数据库表规模过大，指单一数据库表的记录数在百万行以上，对这类表直接进行检索而不采取必要的优化手段，必然造成单一查询响应时间过长。如果数据库表的规模一再增大，使用索引也不能很有效地解决响应时间过长的问题。对此类问题，可采用的解决办法是对数据进行分布，使查询能够并行执行或缩小查询的范围。
c．查询优化
查询优化对响应时间的影响不容忽视。实际上一条结构化查询语句（SQL）的写法有多种，不同的写法可能有不同的响应时间。如果开发人员在软件编写过程中恰好使用了执行效率低的SQL语句，其响应时间自然就会变长，应执行最快的SQL语句。但由于数据库本身动态变化，执行最快的SQL语句也可能变化，所以该方法有局限性。
d．事务粒度过大
事务粒度过大指单一数据库事务执行过程中，需要以某种并发控制机制访问多个数据库资源。通常采用的并发控制机制是互斥锁或者共享锁。这种大粒度事务的执行由于要访问多个数据库资源（如数据库表），本身就需要消耗相当长的时间。此外，由于通常事务在执行的时候会对数据库资源进行加锁，这类事务也对其他访问该资源的用户造成影响。这类事务通常使用的锁数量都在两个以上，如果不合理地进行控制，极容易造成死锁。因此，在应用软件设计过程中，应该尽量消除大粒度事务。
③批任务对普通用户性能的影响
a．概述
批任务指一次操作将对数据库中大量数据进行互斥访问的数据库事务。该类型的事务通常将更新同一数据库表中的数千项乃至更多的数据。由于这类任务把所有操作放置在同一个数据库事务中，所访问的资源在其执行过程中始终被锁定，必然会对其他普通事务造成访问影响。此外，由于这类任务本身将对数据库服务器造成巨大的负担，使得服务器负载加重，从而影响独立事务的响应时间。
b．注意事项
通常，批任务推荐在系统具有较长空闲时完成（如晚上），可以保证不对独立事务造成影响。如果要求批任务必须与独立事务混合运行，则必须对其加以改造，以减轻对其他事务的影响。
（2）并发处理能力差
a．概述
并发处理能力差指应用系统在执行同一类型事务的多个实例时，不能获得与执行实例数量相当的吞吐量，而大大低于理论值。通常并发执行中的某个实例以互斥方式对资源进行访问，造成其他同类型用户必须等待该实例释放锁定资源后才能执行。
b．注意事项
由于某些资源必须以互斥的方式进行访问，所以某些类型的事务在同一时间只能有一个进行执行。对于并发处理能力差的问题采用降低同一类型事务中锁的粒度、优化应用逻辑以缩短单一类型事务响应时间等方法。
（3）锁冲突严重
锁冲突是各以关系数据库为核心信息系统必须解决的问题。此处锁冲突指同一类型或不同类型事务在并发执行时，由于资源互斥而相互影响，造成一个或多个事务无法正常执行。
①内容
锁冲突严重包括以下两个方面：
a．资源锁定造成的数据库事务超时
原因如下：
第一，批任务影响其他类型独立事务的情况；
第二，某些改造过的批任务由于频繁对特定资源进行锁定；
第三，某些某些大粒度事务在并发执行的实例较多时，会造成同类或不同事务的数据库超时；
第四，应用系统没有健壮的异常处理机制，很可能造成锁资源不被释放（即，开始的事务既没有提交也没有回滚）。该错误发生时，必然造成资源被长久锁定。
b．数据库死锁
数据库死锁可以看作进程间死锁的一种特殊情况，故可以采取与处理操作系统死锁相类似的方法解决数据库死锁的问题。造成死锁必须具备下述条件：
第一，互斥条件：各资源被分配给特定的进程，或者可用；
第二，持有并等待条件：被授权持有资源较早的进程可以请求新的资源；
第三，不可取代原则：事先被赋予的资源不能够从该进程中被强制取走，必须被所持有的进程明确释放；
第四，环等待条件：必须存在两个或者多个进程的环形链，其中各进程都等待由环形链的下一个成员所持有的资源。
注意：由于没有充分考虑软件开发人员对资源争用可能造成的死锁问题，目前主流数据库管理系统主要采用乐观的并发控制算法，导致应用系统实际使用过程中频繁发生死锁。但是一般情况下，同类型数据库事务的不同实例之间不会发生死锁，如果不同类型事务之间如果没有按照一个统一的契约进行并发访问，将极容易形成死锁。因此，在确保应用系统功能的前提下，制定一个不同事务之间进行并发访问的原则，就可以有效消除环等待，减少死锁发生的可能性。
②解决办法
一套适用于解决已发布系统性能问题的通用方法，步骤如下：
a．监视性能相关数据；
b．定位占用较大资源的事务并做出必要的优化或调整；
c．定位锁冲突，修改锁冲突发生严重的应用逻辑；
d．对规模较大的数据或者无法通过一般优化解决的锁冲突进行分布。
（4）监视并记录性能相关数据
①概述
对数据库服务器软件、操作系统、网络环境乃至客户端等各类处理单元的性能相关信息进行监视并记录，是发现数据库性能问题的基础。该步骤的作用是搜集相关的数据，作为分析性能问题的基础。由于各处理单元的状态变化，性能数据的监视与采集须采取快照的方式，尽可能详细记录下所有时间点上各处理单元状态信息。相邻采样时间点之间的间隔越小，状态信息就越准确。
②重点
a．状态信息：代表单一数据库会话在其生命周期中的状态变化情况，包括在什么时间点开始一个事务，在什么时间点被其他会话锁定，何时超时等；
b．执行的结构化查询语句：代表单一数据库会话在其生命周期中执行的所有数据库操作；
c．锁使用情况：代表整个数据库服务器的锁资源使用和变化情况。
此外，顺序扫描、高代价查询等属性也是代表数据库服务器性能的重要数据。
（5）定位资源占用较大的事务并做出必要的优化或调整
一个事务同时占用大量数据库锁的应用逻辑事务，通常这类事务都属于批任务。为了减少资源消耗，最好将其放置在系统具有充分空闲时间时进行。
（6）定位锁冲突，修改锁冲突发生严重的应用逻辑
导致应用系统锁冲突频繁发生的原因非常复杂，主要表现：事务粒度过大、响应时间过长、异类事务互相影响并形成死锁等。通过对数据库锁使用情况信息的分析，可以定位发生锁冲突的各会话。在此基础上对发生锁冲突的会话各自的执行状态变化和结构化查询语句进行分析，可以定位发生锁冲突的应用逻辑源程序。如果造成锁冲突的是同种或者异种普通事务，必须分析确定是否本身粒度过大，数据访问是否存在瓶颈等。对这类事务的优化相对较难，一般需开发人员的经验和对应用逻辑本身特性的了解。
（7）进行必要的数据分布
数据分布的主要目的为：通过数据库服务器的并行执行特性，使得单一事务的执行具有较短的响应时间和不同类的事务之间影响相对缩小。
①在缩短响应时间方面，该方法主要适用于对规模较大的数据库表进行访问。不仅使得特定的查询可以并行执行，而且有可能改变结构化查询语句的执行计划，缩小查询进行的范围。
②对于异类事务之间，或者同类事务的不同实例锁冲突频繁的问题，可以通过数据分布加以解决。
③通过监视并记录应用系统处理单元性能的相关数据，定位性能问题的方法，可帮助开发人员有效发现系统中存在的主要性能问题。
注意：解决数据库性能问题是一个迭代和往复的过程，通常需要在各种条件的矛盾之间寻求合理的平衡点。
5．Oracle与提高性能有关的特性
（1）简介
以Oracle为例，讨论数据库优化的方法。不同的方法，优化的方法也不同。如果测试人员了解这些方法，可以更好地分析、定位数据库性能问题，制定有针对性的测试用例。
Oracle与提高性能有关的特性主要包括：索引、并行执行、簇与散列簇、分区、多线程服务器以及同时读取多块数据等。以下为Oracle配置的关键参数及其使用方法：
①max_dspatchers：指定系统允许同时进行的调度进程的最大数量；
②max_shared_servers：指定系统允许同时进行的共享服务器进程的最大数量。如果系统中出现人为死锁过于频繁，则管理员应该增大该参数的值；
③parallel_adaptive_multi_user：当该参数值为true时，系统将启动一个能提高使用并行执行方式的多用户系统性能的自适应算法，该算法将根据查询开始时的系统负载自动降低查询请求的并行度；
④parallel_automatic_enabled：如果将该参数的值设置为true，则Oracle将确定控制并行执行的参数的默认值；
⑤parallel_broadcast_enabled：该参数允许管理员提高散列连接和合并连接操作的性能，这样的连接操作中，系统将一个大尺寸的结果集与一个小尺寸的结果集连接在一起；
⑥parallel_execution_message_size：该参数指定系统并行执行时的消息尺寸；
⑦parallel_max_servers：指定实例能同时运行的并行执行进程和并行恢复进程的最大数量。随着用户需求的增长，创建实例时，该参数设置的值将不再能满足用户需求，所以应当增大该参数的值；
⑧parallel_min_percen：系统将联合使用paralle_max_servers,parllel_min_servers和该参数。该参数允许指定并行执行进程（即参数parallel_max_servers之值）的最小百分比；
⑨parallel_min_servers：该参数指定实例并行执行进程的最小数量。其值是实例启动时Oracle创建的并行执行进程数；
⑩parallel_threads_per_cpu：该参数指定实例默认的并行度和并行自适应以及负载平衡算法。指明并行执行过程中一个CPU能处理的进程或线程数；
⑪partition_view_enabled：该参数指定优化器是否使用分区视图，Oracle推荐用户使用分区表而不是分区视图。分区视图只是为了提供Oracle的后向兼容性；
⑫recovery_parallelism：该参数指定恢复数据库系统时使用的进程数。
（2）索引
①简介
在数据库系统中，索引是一种可选结构，其目的是提高数据访问速度。利用索引可提高用户访问数据的速度，或直接从索引中独立检索数据。如果对索引的配置和使用进行优化，则索引能大大降低数据文件的I/O操作，并提高系统性能。
但是为一个表创建索引后，Oracle将自动维护该索引。当用户在表中插入、更新或删除记录时，系统将自动更新与该表相关的索引。一个表可以有任意数量的索引，造成的系统开销也越大。
索引是建立在表的一个或多个字段之上的。索引的作用大小取决于该字段或字段集的选择性。选择性指索引能降低数据集中的程度。如果表中与某个索引相关的字段值各不相同，则该索引就有很好的选择性。一个索引可能只能帮助管理员降低检索的记录数，而不能唯一地确定一条记录。
②有效创建和使用索引的技巧和方法
索引的选择性越好，就越有助于提高数据访问速度。以下为有效创建和使用索引的技巧和方法：
a．索引和降低系统处理的数据量
索引的主要作用之一就是降低系统处理的数据量。在对CPU使用和等待完成I/O操作的时间上，I/O操作引起的系统开销非常昂贵。降低I/O操作可提高系统性能和处理能力。
第一，如果不使用索引，则为找到特定的数据，系统将不得不扫描表中的所有数据
第二，某些情况下，索引必须返回大量数据
例如：
SELECT *
FROM customers
WHERE region='North'
该查询语句很可能返回大量数据，因为索引操作返回了大量记录的ID，并且系统必须独立访问这些记录的ID，故此时不使用索引可能比使用索引的效率更高。不同的数据，在某些情况下位图索引可能非常有用，而在另外一些情况下，使用位图索引可能没有任何好处。
b．索引和更新
如果对表创建了索引，则更新、插入和删除表中的记录都将导致额外的系统开销。系统提交这些操作前，系统将会更新所有与该表相关的索引，这可能需花费很长时间，并额外增加一定的系统开销。
c．在字段选择性很低的情况下适用索引
第一，原因
位图索引能在字段选择性不高时工作得很好。一个位图索引可以和其他位图索引联合使用，以降低系统检索的数据集。对于某些值为true/false、yes/no或其他小范围数据的字段，建立位图索引非常合适。
注意：位图索引所占用的空间，是随着与该索引相关的字段的不同值的数量的增加而增加的。
第二，创建索引的方法
对于不同的表，可能会选择一个或多个字段创建索引。可使用以下方法来确定在哪些字段上创建索引：
i．选择那些最常出现在where子句中的字段；
ii．经常用于连接表的字段是创建索引的必然候选字段；
iii．必须注意索引导致的查询语句性能的提高与更新数据时性能的降低之间的平衡；
iv．经常被修改的字段不适合创建索引，其原因是，更新索引将增加系统开销。在某些情况下，使用复合索引的效率可能比使用简单索引的效率更高。
第三，使用复合索引的情况
i．某两个字段单独都不具有唯一性，结合在一起却有唯一性的情况；
ii．如果select语句中的所有值都位于复合索引中，则Oracle将不会检索表，而直接从索引中返回数据；
iii．如果多个查询语句的where子句中，作为查询条件的字段都不相同，但返回的记录相同的情况。
第四，注意事项
i．创建索引之后，开发人员应当定期察看用户查询是否充分利用了索引。有必要试验使用索引和未使用索引在效率上的差别，以判断索引所耗费资源是否物有所值；
ii．应删除不经常使用的索引；
iii．如果为不适合创建索引的字段或表创建了索引，则可能会导致系统能力的下降，而如果创建的索引合理，则将降低系统的I/O操作并加快访问速度，从而大大提高系统性能。
（3）Oracle的并行执行特性
对于表扫描而言，系统花费在等待数据从磁盘返回的时间常常比处理数据所花费的时间还长。通过并行机制，可实现当一个进程在等待I/O操作时，CPU可执行另一个进程。Oracle的某些功能由多个服务器进程协同处理，这些功能包括查询、创建索引、加载数据和恢复数据库。所有功能都遵循充分利用CPU资源的规则。
RDBMS的绝大多数操作都可分为以下3类：
①被CPU限制的操作
这类操作的速度同单CPU运行速度，通过并行化操作，多个CPU可并行处理系统负载，故可以更快完成该操作。
②被I/O限制的操作
这类操作花费了绝大部分时间等待系统完成I/O操作。当系统中同时出现多个I/O请求时，绝大多数raid控制器将很好地工作。另外，当一个线程需要等待完成I/O操作时，可充分利用CPU来处理另一线程的CPU部分。
③被竞争限制的操作
并行处理不能改善由资源竞争所限制的操作。
并行执行使Oracle的某些功能由包括查询、创建索引、加载数据和恢复数据库等由多个服务器协同进行处理成为可能。所有这些功能都遵循一充分利用CPU资源这一原则。下面对这些功能进行介绍：
①并行查询处理
a．概述
并行查询处理允许多个服务器进程以并行方式处理某些Oracle语句。
并行查询操作将该查询分为不同的部分，每部分由不同的服务器进程进行处理，这些进程称为查询服务器。一个被称为“查询协调者”的进程负责调度这些查询服务器。系统将一个SQL语句和一个并行度提交给查询协调进程，而协调进程则负责将该查询分配给查询服务器，并将各查询服务器返回的结果组合成一个整体。并行度指分配给该查询的查询服务器数量。Oracle服务器能对连续、排序以及表扫描操作实现并行执行。
b．特点
第一，在多处理器或并行处理计算机上，并行查询操作非常有效；
第二，在单处理器计算机上，如果大部分时间都花在了等待系统完成I/O操作上，则使用并行查询也是非常有效的。具有足够I/O带宽的系统，尤其是使用磁盘阵列的系统，都能从并行查询操作中受益。
通常如果系统CPU的使用率达到100%，且系统中只有少量磁盘驱动器或者如果系统的内存非常紧张，并行查询没有意义。
c．考虑并行度的因素
并行查询中，合理的I/O分布和并行度是最需要调整的两方面。对并行度的调整一方面需要反复的试验，另一方面还需一定的分析。应当首先根据以下因素考虑并行度：
第一，计算机的CPU的数量和能力将影响系统能运行的查询进程数量；
第二，系统处理大量进程的能力因操作系统而异；
第三，系统运行接近或者已经达到极限，并行度的调整效果不大甚至使系统不堪重负；
第四，系统处理的查询数量很少，大部分操作是更新操作，则开发人员可能希望系统运行多个查询进程；
第五，对系统的I/O能力有一定的要求，如果磁盘上的数据是分片或使用磁盘阵列存储的，则系统能够处理多个并行查询；
第六，系统是否需要处理很多的全表扫描或排序，并行查询服务器非常有助于这类操作。
d．并行度的另外建议
第一，诸如排序之类，需要大量CPU资源的操作应当采用较低的并行度。原因是这类受限于CPU的操作已经充分利用CPU，而不需等待系统的I/O操作。
第二，诸如全表扫描之类，需要大量磁盘I/O的操作，应当采用较高的并行度。需要等待磁盘I/O的操作越多，系统就越能受益于并行操作。
第三，如果系统中有大量的并发进程，那么应当采用较低的并行度。因为太多的进程将使系统不堪重负。
②并行创建索引
并行查询的另一个特征是以并行方式创建索引能力，通过该特性，系统用于创建索引的时间将大大减少。类似于并行查询操作，并行创建索引操作有两组查询服务器，如下：
a．第一组查询服务器的功能是扫描需要创建索引的表，以获得ROWID和与索引相关的字段值。
b．第二组查询服务器则对第一组查询服务器所得到的值进行排序，并将排序后的结果传递给协调进程，而协调进程再根据这些排序后的条目创建B树索引。
③并行加载数据
通过使用多个并发会话，同时往同一个表中写数据，可实现数据加载的并行化。对于不同的系统配置，通过并行方式加载数据，可提高数据加载性能。并行化数据加载将通过多个直接加载器进程实现。并行加载数据非常有用，特别是在数据加载时间很紧张的环境中尤其如此。通过将各输入文件放置在不同的卷上，可提高并行加载数据的性能。并行查询操作中所有的通用调整原则都适用于并行加载数据操作。
④并行恢复
并行恢复是并行查询选项的一个重要特性。在评估Oracle和测试软硬件时，需要有意地使系统崩溃，以检验系统的可恢复性。通过使用并行恢复选项，将恢复数据库和实例的时间将大大缩短。在并行恢复方式中，一个进程负责从重做日志中读取和调度重做入口，并将这些入口传递给恢复进程，而恢复进程则负责将用户对数据库所作的修改写进数据库中。
当被恢复的系统有很多磁盘并支持异步I/O操作时，系统恢复所用的时间将会大大缩短。对于只有很少磁盘的小系统或不支持异步I/O的系统，采用并行方式恢复系统是不明智的。
总之，在平衡操作负载方面，并行查询选项非常有用，当其他进程在等待系统完成I/O操作时，并行查询可使CPU转而处理其他进程，从而充分利用系统的CPU资源。对于多处理器计算机，使用并行查询非常有用，但并不是并行查询不能用于单处理器计算机。
（4）簇（索引簇）
①简介
簇是Oracle数据库中用于存储表的一种方法。在一个簇中，系统将多个相关的表存储在一起，以缩短用户访问相关记录的时间。只有当这些相关表经常被同时访问时，才适合使用簇。对用户和应用程序而言，簇的存在是透明的，簇只影响数据的存储方式。
②应用
在某些情况下使用簇有时非常有利有时非常不利，应当仔细考虑簇是否有助于提高系统性能。
a．有利的情况
通常，如果集中存放的数据主要用于连接表中，则使用簇很好。如果两个表存放了相关数据，并且这两个表经常被同时访问，通过使用簇可将相关数据预装入SGA中，从而提高用户访问数据的性能。
b．不利的情况
一般，如果开发人员不会同时使用以上的信息，簇将不能提高系统性能，并且该情况下，簇实际上会导致系统性能的轻微下降。簇的另一个缺点在于，当用户执行insert语句时将降低系统性能。引起性能下降的原因是簇在使用存储空间上采用的方法更加复杂，并且系统需将多个表存储在同一个数据块中。簇表比单个表占用了更多的存储空间，将导致系统扫描更多的数据。如果系统经常对以上表中的某个表作全表扫描，不应当为这些表创建簇，会降低系统的性能。
（5）散列簇
散列簇采用散列函数访问簇键，根据散列函数的计算结果保存数据。散列函数是数学函数，该函数根据散列键的值来确定簇中的数据块。不必为所有表创建散列簇。经常为一个单独的表创建散列簇，以利用散列簇的特性。通过使用散列索引，系统只需一次I/O操作，就能检索到用户所需数据，如果使用B索引，系统需要多次I/O操作才能检索到需要的数据。适合创建散列簇的表具有以下特征：
①簇键值具有唯一性；
②用户对表的大部分查询都是关于键值的等式查询；
③表的尺寸是静态的，几乎不会出现任何增长；
④簇的键值不会发生任何变化。
用户使用关于簇键的等式查询检索数据时，散列簇具有很高效率。如果用户不根据簇键值检索数据，该查询就不能被散列化。例如当在散列簇表中使用insert语句时，将降低系统性能。
（6）同时读取多块数据
当系统执行表扫描时，Oracle具备同时读取多个数据块的能力，该能力提高了系统的I/O速度，避免了对磁盘上数据进行搜索的操作。通过降低磁盘搜索和读取更大的数据块，可降低系统的I/O开销和CPU开销，该特性被称为多块读取。只有对于连续数据块，多块读取特性才有助于提高系统性能。通常，一个盘区内的数据块都连续。。为充分发挥多块读取数据的优势，尽量配置系统以使数据库的块连续，应当使用优化尺寸的盘区来创建数据库。盘区的尺寸应当远大于一次多块读取操作所读取的数据的尺寸。
Oracle初始化参数db-file-multiblock-read-count指定了一次多块读取能读取的数据量。因为该参数几乎不会导致系统性能的下降，一般，都将该参数的值设置得很高。I/O的尺寸取决于初始化参数
db-file-multiblock-read-count和db-block-size的值。
（7）分区（partition）
该特性的目的是允许大尺寸表或索引分解成小的更容易管理的部分。与原来的表或索引相比，分区变小，所以系统访问分区的速度更快，效率也更高。可将分区想象成表或索引被分解之后的多个小尺寸的表或索引。系统可单独访问这些小尺寸的表或索引，也可以以组或整体的方式访问。
①创建分区的方案
a．Range Partitioning：该方案根据数据的范围，比如月、年等对表中的数据进行分区；
b．List Partitioning：该方案和Range Partitioning分区方案很类似，但该方案是按照数据的值，而不是数据的范围进行划分；
c．Hash Partitioning：该分区方案使用散列函数来实现对数据的自动分区；
d．Sub-Partitioning：该方法就是开发人员熟悉的复合分区方法，允许开发人员同时使用多种分区方案。
②分区的优点
a．可降低I/O操作和CPU的使用率；
b．可在分区的层次上而不是表的层次上加载数据；
c．能以删除分区的方式删除大量数据；
d．对用户和应用程序而言，分区是完全透明的；
e．可在分区层次上而不是在表层次上维护数据。
（8）多线程服务器
①简介
因为每一个专用服务器进程都将占用大量内存资源和系统资源，所以有必要对多用户连接采用多线程服务器进程。
多线程服务器进程允许多个用户使用一定数量的共享服务器进程。所有对共享服务器的请求都须经过调度进程，该过程对SGA大缓冲池中的用户对共享服务器进程的请求进行排队。当系统处理完用户请求后，系统通过SGA中的大缓冲池将请求结果返回给调度进程。多线程服务器会增加系统开销。对配置和调整多线程服务器，需要调整参数文件中的参数，还应小心监控系统的大缓冲池，以确保系统的运行没有超出分配给其的内存空间。
②参数
a．基本参数
应尽量监控只有少量用户的共享会话所使用的内存。监控结果会告知共享会话使用多少内存。利用这些数据，能估算所有会话总共需要多少内存。将使用的总内存量除以连接数，就可确定各会话使用的内存数量。然后就可从各会话使用的内存量来推算为了支持系统的所有会话，需要为系统的大缓冲池分配多大内存空间。基本参数如下：
第一，large_pool-size：可通过调整初始化参数largepool-size来增加大缓冲池的内存空间。
注意：除多线程服务器之外，系统还使用大缓冲池来执行并行查询操作。
第二，mts_dispatchers：初始化参数mts_dispatchers决定各网络协议使用的调度进程的数量。
b．其他相关参数
第一，mts_max-dispatcher：实例能创建的调度进程的最大数量。此处调度进程包括所有网络协议的调度进程；
第二，mts_servers：实例刚启动时的共享服务器进程数。如果将该参数设置为0，Oracle将不会是用共享服务器进程；
第三，mtx_max_servers：该参数指定了实例中允许运行的共享服务器进程的最大数量。
③注意
a．如果应用程序能利用簇和索引的优势，簇和索引将有助于提高系统性能；
b．Oracle并行查询选项和并行服务器选项能极大地提高系统性能，在调整系统时，非常重要的一点是需要注意调整系统所冒的风险；
c．如果对系统需要调整的方面和该调整所影响的方面进行仔细考虑，并对应用程序的数据访问模式有深入了解，可以将调整面临的风险降到最小。应仔细考虑对系统所作的修改将会对系统造成的影响，并尽量了解系统修改对应用程序的影响。
6．测试报告
通常，在测试标志性阶段或者测试结束时需要出具测试报告。测试报告是整个测试的总结，其主要作用是描述测试结果。测试报告的格式不限，但需要验证是否包括以下关键内容：
（1）测试案例说明；
（2）测试结果数据；
（3）测试结果分析；
（4）测试环境说明；
（5）报告术语解释。
8．5 负载压力测试技巧
一、参数池技术
1．简介
录制业务流程时，测试工具生成一个由函数构成的Vuser脚本。函数中参数的值是录制期间使用的实际值。
上例中可以用参数“Book_Title”来替换常量值“UNIX”，然后，生成的Vuser使用指定的数据源中的值来替换参数。该数据源可以是一个文件或者内部生成的变量。
2．对Vuser脚本进行参数化的好处
（1）减小脚本的大小；
（2）提供使用不同的值测试脚本的能力。
3．参数化涉及的任务
（1）用参数替换Vuser脚本中的常量值；
（2）为参数设置属性和数据源。
4．使用参数方法的执行步骤
（1）指示Vuser从外部文件中取值
①选择或者创建数据文件；
②设置参数的属性。
（2）从数据库中导入数据，用于参数化
①新建查询；
②指定SQL语句。
二、将事务插入到Vuser脚本
可以定义事务以度量服务器的性能。各事务度量服务器响应指定的Vuser请求所用的时间。这些请求可以是简单任务，也可以是复杂任务。要度量事务，需要插入Vuser函数以标记任务的开始和结束。在脚本内，可以标记的事务不受数量限制，各事务的名称都不同。在方案执行期间，主控台将度量执行各事务所用的时间。场景运行后，可使用测试工具的图和报告来分析各事务的服务器性能。
三、将集合点插入到Vuser脚本
通过创建集合点，可以确保多个Vuser同时执行操作。当某Vuser到达该集合点时，主控台会将其保留，直到参与该集合的全部Vuser都到达。当满足集合条件时，主控台将释放Vuser。可通过将集合点插入到Vuser脚本来指定会合位置。在Vuser执行脚本并遇到集合点时，脚本将暂停执行，Vuser将等待主控台允许继续执行命令。
四、手工关联
主要是解决动态数据所导致的问题，即利用测试工具的脚本函数如何关联动态且不可人工预知的值。
1．举例
系统的输出值需要为后续操作提供输入，这些值只对当前会话有效。举例说明如下：
（1）系统产生的SessionID；
（2）每次访问Web页面的动态URL；
（3）表单提交期间录制的Field（有时会隐藏）
解决办法如下：
①从一个操作步骤中捕捉输出值；
②该值用于另一个步骤的输入。
2．关联数据的方法
关联数据先由服务器发给客户端，之后客户端又将该数据返回服务器。关联数据的方法如下：
（1）手工关联；
（2）录制结束后自动关联；
（3）录制过程中自动关联。
3．Vuser脚本中关联动态数据的步骤
（1）确定需要捕捉的值
①创建两个虚拟用户
这两个用户的录制步骤保持一致，如果捕捉的动态数据依赖于某个输入值，则改变这个输入值；如果独立于任何输入值，就采用相同的数据。
②对比脚本
利用Wdiff.exe工具对比，遍历脚本的每行，并且亮显不同点。
（2）找到所捕捉值的左右边界标识符；
（3）决定应该使用哪个边界；
（4）将函数web_reg_save_param加入脚本，在加入之前，必须先捕捉到值；
（5）在函数中加入参数名称、左边界标识符、右边界标识符及函数事件；
（6）在每次脚本运行时参数化动态数据；
（7）校验执行结果。
五、IP数据池
1．简介
应用程序服务器使用IP地址来标识客户端，常缓存来自同一台计算机上的客户端信息。运行方案时，每台负载生成器计算机上的Vuser都使用该计算机的IP地址。网络路由器缓存源信息和目标信息，以提高处理能力。如果许多用户使用同一个IP地址，服务器和路由器都会进行优化处理。测试工具多IP地址功能可以使用许多IP地址来标识在一台计算机上运行的多个Vuser，使测试环境更加真实。
Windows平台上，每块网卡上可模拟的最大IP地址数为35个，Solaris（2.5.1版）最多为255个，Solaris（2.6或更高版本）最多则为8192个。
2．多IP地址功能适用于的协议
（1）客户端服务器：DNS、Windows Sockets；
（2）自定义：Java Vuser、Javascript Vuser、VB Vuser、VB Script Vuser；
（3）电子商务：FTP、Palm、SOAP、Web（HTTP/HTML）协议、WinSock\WebDual协议；
（4）bom：Oracle NCA、Siebel-Web；
（5）邮件服务：Internet Messaging（IMAP）、MS Exchange（MAPI）、POP3、SMTP；
（6）流数据：Real；
（7）无线：i-Mode、VoiceXML、WAP。
3．向负载生成器中添加新IP地址
（1）运行负载生成器上的“IP向导”添加指定数量的IP地址，为UNIX负载生成器计算机手动配置新的IP地址；
（2）重新启动计算机；
（3）如有必要，用新地址来更新服务器的路由表；
（4）在控制台中启用这项功能。
六、Web站点经验点滴
（1）在执行客户端并发性能测试的过程中，需要同时监控数据库服务器、Web服务器以及网络资源等使用情况，以便对系统的性能做全面评估
（2）录制的脚本需要编辑，有时需要手工编写脚本
（3）尽可能去录制脚本，然后在其基础上编辑脚本
（4）手工编写脚本需要注意既能够模拟负载压力，又符合脚本的后台处理方式
（5）设置数据池，实现变量替换常量
为真实模拟负载，数据池是经常使用的有效手段。
（6）混合业务批量执行
单独的业务并发操作，有可能会忽略例如资源争用、锁冲突等问题，在Web站点负载压力测试方案中，一定要考虑将多种业务混合执行，并发性能测试。
（7）模拟用户数的递增
高峰期负载压力的到来是循序渐进的过程，同样的道理，高峰期的结束也有一个过程。在工具中使用虚拟用户数的递增与递减来模拟这种情况。
（8）合理设置交易之间的时间间隔
交易之间的时间间隔代表了负载程度的高低，为模拟不同的负载，经常需要调整此时间间隔。
（9）模拟IP地址变量的技术
对于并发访问需求量不大的系统，各不同的虚拟用户使用不同的IP地址访问服务器非常有必要。
（10）超时（timeout）设置
该项设置与系统Web服务器、数据库服务器、中间件服务器等超时设置有关，建议工具的设置值大于等于系统服务器的设置值。
（11）并发用户连续执行交易数的设置
各虚拟用户在并发时，串行循环执行的交易数建议设置为3～5个。
（12）错误跟踪
测试期间的报错是故障定位的主要依据，应该分清错误的来源，包括服务器端错误、客户端错误以及网络错误。
（13）利用动态数据处理技术
对某些动态值，每次执行它都在变化，如果不加处理，往往导致负载测试失败。
（14）尽量将执行负载测试的机器合理分布
将负载生成器布置在不同的网段，有利于模拟来自不同用户群的负载。
（15）并发用户数量极限点
压力测试的目的是测试系统能够支持的最大并发用户数。
（16）负载生成器的资源使用率也有必要监控
负载生成器的资源使用超出范围，导致模拟客户端并发请求失败。
（17）设置并发集合点
在脚本中设置并发集合点，可以将录制的完整操作过程分解为一个个小的并发交易。
（18）工具参数的配置
工具参数的配置非常灵活且有效。
七、脚本调试技术
以下为脚本调试的例子。
1．TUXEDO
该类中间件，脚本处理的重点如下：
（1）管理TUXEDO缓存；
（2）在TUXEDO命令之间传输数据。
2．Winsock
Winsock脚本调试重点是在脚本中如何用变量来代替定值，即处理Winsock应用程序数据流。下面的示例脚本可参见http://yuanhaisong.myip.org/sqa/webtest.htm。原始脚本如下：
修改后的脚本如下：
3．SQLServer
这一类数据库，脚本处理的重点如下：
（1）从存储过程中捕获一个值；
（2）利用检索到的值作为一个参数传递给存储过程。
实例脚本如下：
存储过程定义如下：
脚本代码如下：
①第一步：加入必要的变量说明
②第二步：调用存储过程
调用存储过程，然后修改其返回值。
原始脚本代码：
修改后的代码（使用字符串值）：
八、测试工具配置技巧
在测试工具中，不同的配置有不同的测试结果。根据实际负载压力需求正确地配置参数，可以保证达到真实地模拟负载，并得出正确的测试结果。以下举例说明配置参数：
（1）Form Field Comments(Yes/No)：在脚本中是否给FormField部分加注释；
（2）Anchors as Comments(Yes/No)：在脚本中是否给Anchors部分加注释；
（3）Client Maps Comments(Yes/No)：在脚本中是否给ClientMaps部分加注释；
（4）Debug Comments(Yes/No)：在脚本中是否给Debug部分加注释；
（5）Doc Title Verification(Yes/No)：脚本录制过程中是否校验文档：Title；
（6）Baud Rate Emulation(Yes/No)：在脚本回放过程中是否模拟不同的带宽进行回放，如果需要，标明回放的带宽数值；
（7）Encode DBCS Characters(Yes/No)：是否将DBCS字符编码；
（8）Cache(Yes/No)：在脚本回放过程中，是否模拟缓存；
（9）Dynamic Redirect(Yes/No)：在脚本回放过程中，是否支持动态重定向；
（10）Dynamic Cookies(Yes/No)：在脚本回放过程中，是否支持动态Cookies；
（11）Process Subrequests(Yes/No)：在脚本回放过程中，是否支持进程子请求；
（12）Persistent Connections(Yes/No)：在脚本回放过程中，连接是否持久保持；
（13）Max Current Connection：在脚本回放过程中，最大当前连接数，默认值为4；
（14）Max Connection Retries：在脚本回放过程中，最大当前连接重试数，默认值为4；
（15）Server Response Timeout：在脚本回放过程中，服务器响应超时限制，默认值为120；
（16）HTTP Version Detection：录制时采用的HTTP版本，默认值为Auto，既可以为1.0版本，也可为2.0版本，测试工具自动处理；
（17）Active Data(Yes/No)：在脚本回放过程中，是否支持动态数据；
（18）IP Spoofing(Yes/No)：在脚本回放过程中，是否支持每个虚拟用户使用不同的IP实现并发；
（19）Streaming Media(Yes/No)：是否支持流媒体；
（20）Hostnames as IP Addresses(Yes/No)：是否支持使用IP地址标识主机；
（21）Strip All Cookies From Requests(Yes/No)：在脚本回放过程中，请求中是否包括Cookies；
（22）Traffic Filters(Yes/No)：在脚本回放过程中，是否需要流量过滤。