2023年6月29日发(作者：)

性能测试调研报告

1 概述

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

1.1 应用在客户端上性能的测试

应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

并发性能测试是重点

并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress

Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。

并发性能测试前的准备工作

测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。

测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。目前，成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。

测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。 模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

并发性能测试的种类与指标

并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java Script等不同的监控对象，支持Windows和UNIX测试环境。

最关键的仍然是测试过程中对监控对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择Java Script监控对象，手工编写脚本，可以达到测试目的。

采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。

并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90％：90％事务处理的服务器响应时间）、虚拟并发用户数。

疲劳强度与大数据量测试

疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。

一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。 大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。

速度测试目前主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。

1.2 应用在网络上性能的测试

应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

网络应用性能分析

网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如Application Expert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用Application Expert调整应用在广域网上的性能；Application Expert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。

网络应用性能监控

在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。

网络预测

考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。

从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。 PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。

1.3 应用在服务器上性能的测试

对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控，测试原理如下。

UNIX资源监控指标和描述

监控指标

平均负载

冲突率

进程/线程交换率

CPU利用率

磁盘交换率

接收包错误率

包输入率

中断速率

输出包错误率

包输出率

读入内存页速率

写出内存页速率

内存页交换速率

进程入交换率

进程出交换率

系统CPU利用率

用户CPU利用率

磁盘阻塞

描述

系统正常状态下，最后60秒同步进程的平均个数

在以太网上监测到的每秒冲突数

进程和线程之间每秒交换次数

CPU占用率（％）

磁盘交换速率

接收以太网数据包时每秒错误数

每秒输入的以太网数据包数目

CPU每秒处理的中断数

发送以太网数据包时每秒错误数

每秒输出的以太网数据包数目

物理内存中每秒读入内存页的数目

每秒从物理内存中写到页文件中的内存页数目或者从物理内存中删掉的内存页数目

每秒写入内存页和从物理内存中读出页的个数

交换区输入的进程数目

交换区输出的进程数目

系统的CPU占用率（％）

用户模式下的CPU占用率（％）

磁盘每秒阻塞的字节数

2 为什么进行性能测试？

目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。

2.1 性能测试的目的

（1）．评估系统的能力：测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。

（2）．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。

（3）．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。

（4）．检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。

（5）．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

2.2 性能测试的类型

性能测试类型包括负载测试，强度测试，容量测试等

负载测试：Load testing（负载测试），通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

强度测试：强度测试检查程序对异常情况的抵抗能力，是检查系统在极限状态下运行的时候性能下降的幅度是否在允许的范围内。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。 容量测试：通过性能测试，如果找到了系统的极限或苛刻的环境中系统的性能表现，在一定的程度上，就完成了负载测试和容量测试。容量还可以看作系统性能指标中一个特定环境下的一个特定性能指标，即设定的界限或极限值。

容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。软件容量的测试能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如是不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。

观察指标：

性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

在实际中作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？

BS结构程序一般会关注的通用指标如下（简）：

Web服务器指标：

* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；

* Successful Rounds ：成功的请求；

* Failed Rounds ：失败的请求；

* Successful Hits ：成功的点击次数；

* Failed Hits ：失败的点击次数；

* Hits Per Second ：每秒点击次数； * Successful Hits Per Second ：每秒成功的点击次数；

* Failed Hits Per Second ：每秒失败的点击次数；

* Attempted Connections ：尝试链接数；

CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：

* User 0 Connections ：用户连接数，也就是数据库的连接数量；

* Number of deadlocks ：数据库死锁；

* Butter Cache hit ：数据库Cache的命中情况

当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。

我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。

一般软件可以按照系统架构分成几种类型：

c/s

client/Server 客户端/服务器架构

基于客户端/服务器的三层架构

基于客户端/服务器的分布式架构

b/s

基于浏览器/Web服务器的三层架构

基于中间件应用服务器的三层架构

基于Web服务器和中间件的多层架构

3 性能测试的步骤

在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解说，这里只是介绍一种方法提供给你如何选择测试策略，从而帮助分析软件不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。

由于工程和项目的不同，所选用的度量,评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。步骤如下 （1）． 制定目标和分析系统

（2）． 选择测试度量的方法

（3）． 学习的相关技术和工具

（4）． 制定评估标准

（5）． 设计测试用例

（6）． 运行测试用例

（7）． 分析测试结果

3.1 制定目标和分析系统

每一个性能测试计划中第一步都会制定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。

目标：

1． 确定客户需求和期望

2． 实际业务需求

3． 系统需求

系统组成

系统组成这里包含几方面含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试方法来进行测试。

系统类别：分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构,需要掌握 http协议，java，html等技术 。或者是cs结构，可能要了解操作系统，winsock，com等。所以甄别系统类别对于我们来说很重要。

系统构成：硬件设置，操作系统设置是性能测试的制约条件，一般性能测试都是利用测试工具模仿大量的实际用户操作，系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。

系统功能：系统功能指系统提供的不同子系统，办公管理系统中的公文子系统，会议子系统等，系统功能是性能测试中要模拟的环节，了解这些是必要的。 3.2 选择测试度量的方法

经过第一步，将会对系统有清醒的认识。接下来我们将把精力放在软件度量上，收集系统相关的数据。

度量的相关方面：

* 制定规范

* 制定相关流程, 角色，职责

* 制定改进策略

* 制定结果对比标准

3.3 学习的相关技术和工具

性能测试是通过工具，模拟大量用户操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过winsock,http等协议纪录用户操作。而协议选择是基于软件的系统架构实现（web一般选择http协议,cs选择winsock协议），不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。

开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。确定测试工具后，需要组织测试人员进行工具的学习，培训相关技术。

3.4 制定评估标准

任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。

通常性能测试有四种模型技术可用于评估：

*线性投射：用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。

*分析模型：用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来

*模仿：模仿实际用户的使用方法测试你的系统

*基准：定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比 3.5 设计测试用例

设计测试用例是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软件的性能瓶颈。

3.6 运行测试用例

通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不准确的，所以在运行这些测试用例的时候，需要用不同的测试环境，不同的机器配置上运行。

3.7 分析测试结果

运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心系统整体配置会对用户操作的影响。

4 性能测试方法

对于企业应用程序，有许多进行性能测试的方法，其中一些方法实行起来要比其他方法困难。所要进行的性能测试的类型取决于想要达到的结果。例如，对于可再现性，基准测试是最好的方法。而要从当前用户负载的角度测试系统的上限，则应该使用容量规划测试。本文将介绍几种设置和运行性能测试的方法，并讨论这些方法的区别。

如果不进行合理的规划，对J2EE应用程序进行性能测试将会是一项令人望而生畏且有些混乱的任务。因为对于任何的软件开发流程，都必须收集需求、理解业务需要，并在进行实际测试之前设计出正式的进度表。性能测试的需求由业务需要驱动，并由一组用例阐明。这些用例可以基于历史数据（例如，服务器一周的负载模式）或预测的近似值。弄清楚需要测试的内容之后，就需要知道如何进行测试了。

在开发阶段前期，应该使用基准测试来确定应用程序中是否出现性能倒退。基准测试可以在一个相对短的时间内收集可重复的结果。进行基准测试的最好方法是，每次测试改变一个且只改变一个参数。例如，如果想知道增加JVM内存是否会影响应用程序的性能，就逐次递增JVM内存（例如，从1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境数据，记录信息，然后转到下一阶段。这样在分析测试结果时就有迹可循。下一小节我将介绍什么是基准测试，以及运行基准测试的最佳参数。

开发阶段后期，在应用程序中的bug已经被解决，应用程序达到一种稳定状态之后，可以运行更为复杂的测试，确定系统在不同的负载模式下的表现。这些测试被称为容量规划测试、渗入测试(soak test)、峰谷测试(peak-rest test)，它们旨在通过测试应用程序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。对于下面的描述应该从抽象的意义上理解，因为每个应用程序的使用模式都是不同的。例如，容量规划测试通常都使用较缓慢的ramp-up（下文有定义），但是如果应用程序在一天之中的某个时段中有快速突发的流量，那么自然应该修改测试以反映这种情况。但是，要记住，因为更改了测试参数（比如ramp-up周期或用户的考虑时间(think-time)），测试的结果肯定也会改变。一个不错的方法是，运行一系列的基准测试，确立一个已知的可控环境，然后再对变化进行比较。

4.1 基准测试

基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。

注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。

在某一点上，执行队列开始增长，因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。

注意，最初的一段时间，执行队列的长度为零，然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而必须将其排入队列。 当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。

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

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

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

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

4.2 ramp-up测试

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

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

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

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

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

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

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

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

最后，系统中事务的响应时间也遵循着这个波动模式。 注意，每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似，只不过其效果随着时间的推移逐渐减弱。

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

4.3 性能规划测试

对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如，您可能想知道：如果要以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测试，更精确地确定系统的容量。

4.4 渗入测试

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

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

4.5 峰谷测试

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

5 常用性能测试工具

目前市场上的性能测试的工具种类很多，可以简单的划分为以下几种：负载压力测试工具、资源监控工具、故障定位工具以及调优工具。

5.1 主流负载性能测试工具

负载性能测试工具的原理通常是通过录制、回放脚本、模拟多用户同时访问被测试系统，制造负载，产生并记录各种性能指标，生成分析结果，从而完成性能测试的任务。

QA Load：Compuware公司的QALoad是客户/服务器系统、企业资源配置（ERP）和电子商务应用的自动化负载测试工具。QALoad是QACenter性能版的一部分，它通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能。QACenter汇集完整的跨企业的自动测试产品，专为提高软件质量而设计。QACenter可以在整个开发生命周期、跨越多种平台、自动执行测试任务。 （无下载源）

优点：轻量级性能试工具，简单易用。

缺点：中文论坛很少，支持的插件太少。

SilkPerformer：一种在工业领域最高级的企业级负载测试工具。它可以模仿成千上万的用户在多协议和多计算的环境下工作。不管企业电子商务应用的规模大小及其复杂性，通过SilkPerformer，均可以在部署前预测它的性能。可视的用户化界面、实时的性能监控和强大的管理报告可以帮助我们迅速的解决问题，例如加快产品投入市场的时间，通过最小的测试周期保证系统的可靠性，优化性能和确保应用的可扩充性。 （无下载源）

LoadRunner：一种较高规模适应性的，自动负载测试工具，它能预测系统行为，优化性能。LoadRunner强调的是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的确认和查找问题。此外，LoadRunner 能支持最宽范的协议和技术，为您的特殊环境，量身定做地提供解决方案。

LoadRunner 是一种预测系统行为和性能的负载测试工具，通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试，LoadRunner 适用于各种体系架构，能支持广范的协议和技术（如Web、Ftp、Database等），能预测系统行为并优化系统性能。它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。Loadrunner是一个强大有力的压力测试工具，它的脚本可以录制生成，自动关联。测试场景面向指标，实现了多方监控。而且测试结果采用图表显示，可以自由拆分组合。通过Loadrunner的测试结果图表对比，你可以寻找出系统瓶颈的原因，一般来说可以按照服务器硬件、网络、应用程序、操作系统、中间件的顺序进行分析。

特点：

1、 创建真实的负载

用LoadRunner的Controller,能快速组织起多用户的测试方案，并提供一个互动的环境，在其中既能建立持续且循环的负载，又能管理和驱动负载测试方案。同时，可以利用日程计划服务来定义用户什么时候访问系统以产生负载。这样，就能使测试过程自动化。

2、 实时监测器

LoadRunner内含的实时监测器，在负载测试过程的任何时候，都可以观察到应用系统的运行性能。这些性能检测器实时显示交易性能数据（如响应时间）和其他系统组件包括Application Server, Web Server ，网路设备和数据库的实时性能。

3、 分析结果定位问题

测试完毕，LoadRunner收集汇总所有的测试数据，并提供高级的分析和报告工具，以便迅速查找性能问题并追溯原由。通过分析，能很快的查找到出错的位置和原因并做出相应的调整。

4、 LoadRunner 能够推动成千上万的虚拟用户执行不同的业务流程以模拟已部署的应用程序将面对的生产条件。 能够在推出之前发现隐藏在产品中的性能和伸缩性瓶颈，尽量减少产品停机时间和导致性能低下，并满足服务水平和正常运行时间的需求。 5、 LoadRunner 几乎支持 40 个协议 多于其他任何供应商。它包括 Web、J2EE、.NET、XML、ERP/CRM、无线、Citrix 和客户端 服务器应用程序。

6、 LoadRunner 的非侵入性的、实时的性能监控为测试中系统的所有部分提供的详细指标。这包括 Web 服务器、应用程序服务器、数据库、ERP 和 CRM 系统、防火墙、负载平衡等。 LoadRunner 允许确定可能检测不到的硬件限制和软件配置问题。

7、 LoadRunner 是唯一能够跟踪负载中的单个应用程序组件、为其计时并排除其故障的性能测试解决方案。用户能够深入发掘最终用户的低速交易、有瓶颈的方法或可能导致低速的 SQL 语句。 数据细微层次确保每个负载测试为开发提供可操作的结果，从而降低优化 J2EE 和

Siebel 部署所需的时间和成本。

优点：企业级工具，简单易用，中英文网上论坛很多，非常符合BS/CS架构系统测试，国内使用最多的性能测试工具之一。

缺点：很多支持插件（如delphi）需要另外购买，对于复杂的性能测试要求测试员必须具有C语言开发经验，需要适当的培训。价格昂贵。对于数据库性能测试，LoadRunner很困难。

WebLoad：是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能。用户创建的是基于javascript的测试脚本,称为议程agenda,用它来模拟客户的行为,通过执行该脚本来衡量web应用程序在真实环境下的性能。

webload提供巡航控制器cruise control的功能,利用巡航控制器,可以预定义web应用程序应该满足的性能指标,然后测试系统是否满足这些需求指标;cruise control能够自动把负载加到web应用程序,并将在此负荷下能够访问程序的客户数量生成报告。webload能够在测试会话执行期间对监测的系统性能生成实时的报告,这些测试结果通过一个易读的图形界面显示出来,并可以导出到excel和其他文件里。这两个软件的功能虽然强大，并且可以自动生成测试报告，但其终究是一个工具，如果你想真正的定位服务器性能的好坏和性能的瓶颈所在，需要使用工具的人对于测试软件的方方面面都要有了解，比如软件体系构架，网络拓扑，服务器硬件等知识。

优点：非常符合网站的性能测试。

缺点：中文论坛很少。 OpenSTA：开源项目，功能强大，自定义功能设置完备，但设置通过Script来完成。必须学习Script编写。OpenSTA 是专用于B/S结构的、免费的性能测试工具。它的优点除了免费、源代码开放的优点外，还能对录制的测试脚本进行,按指定的语法进行编辑。在录制完测试脚本后，可以对测试脚本进行编辑，以便进行特定的性能指标分析。其较为丰富的图形化测试结果大大提高了测试报告的可阅读性。OpenSTA 基于CORBA

的结构体系，它通过虚拟一个proxy，使用其专用的脚本控制语言，记录通过proxy 的一切HTTP/S traffic。通过分析OpenSTA 的性能指标收集器收集的各项性能指标，以及HTTP 数据，对系统的性能进行分析。

优点：OpenSTA以最简单的方式让大家对性能测试的原理有较深的了解，其较为丰富的图形化测试结果大大提高了测试报告的可阅读性。压力测试引擎具有可扩充性，可以完成打规模的压力测试。提供脚本语言支持。

缺点：

1、脚本语言过于复杂，自定义脚本相当困难

2、仅支持HTTP 1.0 / 1.1 / HTTPS (SSL)协议。

3、没有嵌入虚拟IP、广域网/局域网仿真功能，不支持集合点功能。

4、场景设计方面太过于简单，对于构建一些复杂的场景比较麻烦

5、没有嵌入模拟真实用户不同网络速度的功能。

6、OpenSTA不能跨平台──它是一个只能执行在Windows平台上的负载引擎，不能收集Linux性能数据。

7、使用Repository管理测试脚本、配置等过于简单，保存脚本居然不能自己选择路径。

8、Results结果报告的图表太简陋，功能太少，报告导出功能太简陋。

9、OpenSTA在过去的两年中，都没退出新版本，这个项目已经死掉了。

JMeter：是一款在国外非常流行和受欢迎的开源性能测试工具，像LoadRunner 一样，它也提供了一个利用本地Proxy Server（代理服务器）来录制生成测试脚本的功能，但是这个功能并不好用。

优点：轻量级性能测试工具，Apache JMeter是一个100％的纯Java桌面应用，用于压力测试和性能测量。它最初被设计用于Web应用测试但后来扩展到其他测试，源码开放。

缺点：中文论坛很少，需要二次开发，录制脚本不好用。

WAS(Web Application Stress)：是Microsoft公司下的一款免费产品。WAS允许你以不同的方式创建测试脚本：你可以通过使用浏览器走一遍站点来录制脚本，可以从服务器的日志文件导入URL，或者从一个网络内容文件夹选择一个文件。当然，你也可以手工地输入URL来创建一个新的测试脚本。

优点：

1、简单性

不像其它的工具，你可以使用任何数量的客户端运行测试脚本，全部都有一个中央主客户端来控制。在每一个测试开始前，主客户机透明地执行以下任务：

* 与其他所有的客户机通讯。

* 把测试数据分发给所有的客户端。

* 在所有客户端同时初始化测试。

* 从所有的客户端收集测试结果和报告。

这个特性非常重要，尤其对于要测试一个需要使用很多客户端的服务器群的最大吞吐量时非常有用。

2、高可用性

WAS是被设计用于模拟Web浏览器发送请求到任何采用了HTTP1.0或1.1标准的服务器，而不考虑服务器运行的平台。除了它的易用性外，WAS还有很多其它的有用的特性，包括：

* 对于需要署名登录的网站，它允许创建用户帐号。

* 允许为每个用户存储cookies 和Active Server Pages (ASP) 的session信息。

* 支持随机的或顺序的数据集，以用在特定的名字-值对。

* 支持带宽调节和随机延迟（“思考的时间”）以更真实地模拟显示情形。

* 支持Secure Sockets Layer (SSL)协议。

* 允许URL分组和对每组的点击率的说明。

* 提供一个对象模型，可以通过Microsoft Visual Basic® Scripting

Edition (VBScript)处理或者通过定制编程来达到开启，结束和配置测试脚本的效果。

缺点：

1、以前面所发请求返回的结果为基础，修改URL参数的能力。

2、运行或模仿客户端逻辑的能力。

3、为所分配的测试指定一个确定数量的测试周期的能力。

4、对拥有不同IP地址或域名的多个服务器的同时测试能力。

5、WAS只支持Windows NT 4.0 SP4或者更高及Windows 2000，对于其他系统，不能获取Perf Counters。

6、WAS测试结果报告不能图形化显示。结果报告可分析性低。

主流负载性能工具的比较图如下：

属性

出品公司

价格

安装配置的复杂性

操作性

支持测试对象

LoadRunner

HP(Mercury)

昂贵

简单

QALoad

Compuware

较贵

简单

WebLoad

Radview

一般

一般

较复杂 简单 简单

各种中间件/数据库/客户/服务器系统、企Web Application

应用服务器的性能监控业资源配置(ERP)和/企业架构(j2ee电子商务应用

和.net)的测试

支持平台 windows,unix或linux HP-UX, IBM AIX,Sun Unix

Windows

Solaris, Linux,

NT/2k

支持数据库 DB2,SQLserver, ADO, ADO,DB2,Oracle,SybaOrcale,Sybase DB2,Oracle,Sybase, se,

SQLserver,Odbc SQLserver,Odbc

支持协议 web,http(s),soap,sthttp,ssl,soap,xml, xml,java,ejb,

reaming, streaming,media activex,wap,http,swap,winsock,xml nmp,

real/m$streaming

脚本语言 类似C++ C/C++和VC++

Javascript

自动数据生Y Y Y

成

脚本调试 Y Y Y

报表定制功Y Y Y

能

功能点 创建虚拟用户，创建真预测系统性能、通过强大的专业网站性能实的负载，定位性能问重复测试寻找瓶颈问测试，虚拟多用户

题，分析结果以精确定题、从控制中心管理位问题所在，重复测试全局负载测试、快速保证系统发布的高性创建仿真的测试、验能等 证应用的可扩展性。

虚拟用户上成千上万 成百上千 理论上无限，不过受限数量 机器的限制，同时运行太多影响结果的准确性

可下公司网址 Http://-int .com

载

5.2 资源监控工具

资源监控作为系统压力测试过程中的一个重要环节，在相关的测试工具中基本上都有很多的集成。只是不同的工具之间，监控的中间件、数据库、主机平台的能力以及方式各有差异。而这些监控工具更大程度上都依赖于被监控平台自身的数据采集能力，目前的绝大多数的监控工具基本上是直接从中间件、数据库以及主机自身提供的性能数据采集接口获取性能指标。

首先，不同的应用平台有自身的监控命令以及控制界面。比如UNIX主机用户可以直接使用topas，vmstat,iostat了解系统自身的健康工作状况。另外，weblogic以及websphere平台都有自身的监控台，在上面可以了解到目前的JVM的大小、数据库连接池的使用情况以及目前连接的客户端数量以及请求状况等等。只是这些监控方式的使用对测试人员有一定的技术储备要求，需要自己熟练掌握以上监控方式的使用。

第三方的监控工具相应的对一些系统平台的监控进行了集成。比如Loadrunner对目前常用的一些业务系统平台环境都提供了相应的监控入口，从而可以在并发测试的同时，对业务系统所处的测试环境进行监控，更好的分析测试数据。

但Loadrunner工具其提供的监控方式还不是很直观，一些更直观的测试工具能在监控的同时提供相关的报警信息，类似的监控产品如QUEST公司提供的一整套监控解决方案包括了主机的监控、中间件平台的监控以及数据库平台的监控。QUEST系列监控产品提供了直观的图形化界面，能让测试者尽快进入监控的角色。

性能测试的监控指标主要包括以下几个部分：

1、服务器：Linux应用服务器

具体包括CPU、Memory、Load、I/O、Disk等。

2、数据库：

具体包括缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数等。

3、中间件： 2. Apache

具体包括线程数、连接数、日志输出等。

4、网络

具体包括防火墙、网卡、网线、吞吐量、吞吐率等。 5、应用服务

具体包括JVM内存使用和回收、JAVA内存使用、Full GC频率、JAVA类装入和卸载、日志、线程运行状态（阻塞、等待、正常运行）等。

6、监控工具（LoadRunner）

具体包括用户执行情况、场景状态、事务响应时间、TPS、Load、CPU分析图表等。

7、测试机资源

具体包括CPU、Memory、网络、日志输出、磁盘空间、负载生成器评估等

5.3 故障定位工具以及调优工具

技术的不断发展以及测试需求的不断提升，故障定位工具应运而生，它能更精细的对负载压力测试中暴露的问题进行故障根源分析。在目前的主流测试工具厂商中，都相应地提供了对应的产品支持。尤其是目前.NET以及J2EE架构的流行，测试工具厂商纷纷在这些领域提供了相关的技术产品，比如Loadrunner模块中添加的诊断以及调优模块、

Quest公司的PerformaSure、Compuware的Vantage套件以及CA公司收购的Wily的Introscope工具等等，都在更深层次上对业务流的调用进行追踪。这些工具在中间件平台上引入探针技术，能捕获后台业务内部的调用关系，发现问题所在，为应用系统的调优提供直接的参考指南。

在数据库产品的故障定位分析上，Oracle自身提供了强大的诊断模块，同时，Quest公司的数据库产品也在数据库设计、开发以及上线运行维护都提供了全套的产品支持。

6 服务器与终端连接性能测试点

6.1 服务器性能瓶颈测试点

终端用户访问服务器。找到在同一场景下，服务器允许终端用户访问数量的瓶颈。在测试场景中，需检测的系统资源项，包括如下：

内存分析

内存分析用于判断系统有无内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。 内存分析需要使用的计数器：Memory类别和Physical Disk类别的计数器。内存分析的主要方法和步骤：

（1）首先查看MemoryAvailable Mbytes指标

如果该指标的数据比较小，系统可能出现了内存方面的问题。

（2）注意Pages/sec、Pages Read/sec和Page Faults/sec的值

操作系统会利用磁盘较好的方式提高系统可用内存量或者提高内存的使用效率。这三个指标直接反应了操作系统进行磁盘交换的频度。

如果Pages/sec的计数持续高于几百，可能有内存问题。但Pages/sec值不一定就表明有内存问题，可能是运行使用内存映射文件的程序所致。Page Faults/sec说明每秒发生页面失效次数，页面失效次数越多，说明操作系统向内存读取的次数越多。此事需要查看Pages

Read/sec的计数值，该计数器的阀值为5，如果计数值超过5，则可以判断存在内存方面的问题。

（3）根据Physical Disk计数器的值分析性能瓶颈

对Physical Disk计数器的分析包括对Page Reads/sec和%Disk Time及Aerage Disk Queue Length的分析。如果Pages

Read/sec很低，同时%Disk Time和Average Disk Queue Length的值很高，则可能有磁盘瓶颈。但是，如果队列长度增加的同时Pages

Read/sec并未降低，则是内存不足。

处理器分析

（1）首先看System%Total Processor Time 性能计数器的计数值

该计数器的值体现服务器整体处理器利用率，对多处理器的系统而言，该计数器提醒所有CPU的平均利用率。如果该值持续超过90％，则说明整个系统面临着处理器方面的瓶颈，需要通过增加处理器来提高性能。

（2）查看CPU的Processor%Processor Time 和

Processor%User Time 和 Processor%Privileged Time

Processor%User Time 是系统非核心操作消耗的CPU时间，如果该值较大，可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器， Processor%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。

（3）系统处理器瓶颈 查看 SystemProcessor Queue Length 计数器的值，当该计数器的值大于CPU数量的总数＋1时，说明产生了处理器阻塞。在处理器的%Process Time很高时，一般都随处理器阻塞，但产生处理器阻塞时，Processor%Process Time 计数器的值并不一定很大，此时就必须查找处理器阻塞的原因。

%DOC Time 是另一个需要关注的内容，该计数器越低越好。在多处理器系统中，如果这个值大于50％，并且Processor%Precessor

Time非常高，加入一个网卡可能回提高性能。

进程分析

（1）查看进程的％Processor Time值

每个进程的％Processor Time反映进程所消耗的处理器时间。用不同进程所消耗的处理器时间进行对比，可以看出具体哪个进程在性能测试过程中消耗了最多的处理器时间，从而可以据此针对应用进行优化。

（2）Process/Private Bytes

Process/Private Bytes是指进程所分配的无法与其他进程共享的当前字节数量。该计数器主要用来判断进程在性能测试过程中有无内存泄漏。

网络分析

（1）Network InterfaceBytes Total/sec为发送和接收字节的速率，可以通过该计数器值来判断网络链接速度是否是瓶颈，具体操作方法是用该计数器的值和目前网络的带宽进行相除,结果小于50%.

1Mdit/sec(兆比特/秒)=131072bytes/sec(字节/秒)

1byte=8bit

6.2 提高服务器性能的四个建议

设置最多连接数量

为了保障每个连接的客户端的性能，往往需要在服务器中设置在同一时间内允许的客户端数量的上限。通过这个参数，管理员可以限制客户端的连接数量与连接时间，以节省带宽来提供其他的服务或者提高已有连接的效率。当客户端的连接数量超过这个最高限制后，所有新建的连接都会被拒绝；当然服务器会把拒绝错误信息返回给客户。

允许每次连接可有无限制请求 该选项表示当客户端与服务器建立连接后，每个子进程在结束前所能接受的客户端请求上限。当达到这个上限值之后，这个子进程就会中断。主要是为了避免某些子进程占用过多的服务器资源而导致服务器性能的下降。“设置最多的连接数量”选项主要用来限制客户端的连接数量；而每个客户端在同服务器进行连接的时候可以采用多个子进程与服务器进行连接。

合理配置超时时间

该选项是指客户端提出连接请求并建立起连接后，最大的空闲时间。如果超过这个时间，客户端与服务器之间仍然没有进行任何的接收或者发送信息的动作，则就会中断这个连接。其实这个选项对于访问者来说是一把双刃剑。一方面限制无用的连接时间（客户端连接上服务器而没有进行任何的请求动作）可以减少带宽的浪费，可以保障其他访者着的带宽；但是另一方面这也比较容易引起客户端使用上的不方便。如访问者可能临时有事走开一会儿，客户端与服务器端的连接就会中断。客户端需要重新连接服务器，从而需要进行新一轮的连接请求、身份认证等等，这也会耗用服务器的资源与带宽。所以说，这个超时时间对于双方来说，都是有利又有弊。

慎用允许持久性连接

选中该项内容的话，表示客户端与服务器之间的连接永远有效，除非客户端手工中断与服务器之间的连接。对于这个选项来说，管理员需要慎用。因为根据经验，一般用户不会主动去关闭终端。也就是说，不会主动去中断客户端与服务器端之间的连接。他们很可能会在用完电脑需要关机的时候才会中断这个连接。此时在服务器端虽然有很多客户端的连接数量，但是有不少可能都是“死连接”，在很长的一段时间内不会有数据的传送动作。这对于服务器来说，是一种性能上的浪费。建议宁可把用户与服务器之间的空闲时间设置的长一点，也尽量不要采用持久性连接。