如何进行Web服务的性能测试

贴一篇我们内部的文章：

随着浏览器功能的不断完善，用户量不断的攀升，涉及到web服务的功能在不断的增加，对于我们测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么性能测试都要做些什么呢？我们该怎样进行性能测试呢？

性能测试一般会围绕以下这些问题而进行：

1 什么情况下需要做性能测试？

2 什么时候做性能测试？

3 做性能测试需要准备哪些内容？

4 什么样的性能指标是符合要求的？

5 性能测试需要收集的数据有哪些？

6 怎样收集这些数据？

7 如何分析收集到的数据？

8 如何给出性能测试报告？

性能测试的执行过程及要做的事儿主要包含以下内容：

1 测试评估阶段

在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。

首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。

测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等

2 测试准备阶段

在这个阶段，我们要了解以下内容：

a 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？数据库用的是什么？服务用的是什么语言编写的？；

b 服务端功能的内部逻辑实现；

c 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样操作数据库的？

d 服务端与客户端之间是如何进行交互的，即接口定义；

通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。

e 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；

f 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。

g 了解测试环境与线上环境的不同，例如网络环境、硬件配置等

h 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。

i 沟通上线的指标

通过收集以上信息，确定性能测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。

3 测试设计阶段

根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。

用例编写的步骤大致分为：

a 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。

b 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的操作。

c 验证参数化后脚本功能的正确性。

d 添加检查点

e 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等

4 测试执行阶段

根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。

在测试执行过程中，还要不断的关注以下内容：

a web服务的连接速度如何？

b 每秒的点击数如何？

c Web服务能允许多少个用户同时在线？

d 如果超过了这个数量，会出现什么现象？

e Web服务能否处理大量用户对同一个页面的请求？

f 如果web服务崩溃，是否会自动恢复？

g 系统能否同一时间响应大量用户的请求？

h 打压机的系统负载状态。

5 测试分析阶段

将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。

6 测试验证阶段

在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响。

想看原文或者有测试其他相关的问题可以关注下 搜狗测试 微信公众号，我们上面有不少关于性能测试分享~

　Oracle数据库服务器是整个系统的核心 它的性能高低直接影响整个系统的性能 为了调整Oracle数据库服务器的性能 主要从以下几个方面考虑

　

　◆ 调整操作系统以适合Oracle数据库服务器运行 Oracle数据库服务器很大程度上依赖于运行服务器的操作系统 如果操作系统不能提供最好性能 那么无论如何调整 Oracle数据库服务器也无法发挥其应有的性能

　

　 为Oracle数据库服务器规划系统资源

　

　据已有计算机可用资源 规划分配给Oracle服务器资源原则是 尽可能使Oracle服务器使用资源最大化 特别在Client/Server中尽量让服务器上所有资源都来运行Oracle服务

　

　 调整计算机系统中的内存配置

　多数操作系统都用虚存来模拟计算机上更大的内存 它实际上是硬盘上的一定的磁盘空间 当实际的内存空间不能满足应用软件的要求时 操作系统就将用这部分的磁盘空间对内存中的信息进行页面替换 这将引起大量的磁盘I/O操作 使整个服务器的性能下降 为了避免过多地使用虚存 应加大计算机的内存

　

　 为Oracle数据库服务器设置操作系统进程优先级

　

　不要在操作系统中调整Oracle进程的优先级 因为在Oracle数据库系统中 所有的后台和前台数据库服务器进程执行的是同等重要的工作 需要同等的优先级 所以在安装时 让所有的数据库服务器进程都使用缺省的优先级运行

　

　◆ 调整内存分配

　

　Oracle数据库服务器保留 个基本的内存高速缓存 分别对应 种不同类型的数据 库高速缓存 字典高速缓存和缓冲区高速缓存 库高速缓存和字典高速缓存一起构成共享池 共享池再加上缓冲区高速缓存便构成了系统全程区(SGA) SGA是对数据库数据进行快速访问的一个系统全程区 若SGA本身需要频繁地进行释放 分配 则不能达到快速访问数据的目的 因此应把SGA放在主存中 不要放在虚拟内存中 内存的调整主要是指调整组成SGA的内存结构的大小来提高系统性能 由于Oracle数据库服务器的内存结构需求与应用密切相关 所以内存结构的调整应在磁盘I/O调整之前进行

　

　 库缓冲区的调整

　

　库缓冲区中包含私用和共享SQL和PL/SQL区 通过比较库缓冲区的命中率决定它的大小 要调整库缓冲区 必须首先了解该库缓冲区的活动情况 库缓冲区的活动统计信息保留在动态性能表v$librarycache数据字典中 可通过查询该表来了解其活动情况 以决定如何调整 Select sum(pins) sum(reloads) from v$librarycache; Pins列给出SQL语句 PL/SQL块及被访问对象定义的总次数 Reloads列给出SQL 和PL/SQL块的隐式分析或对象定义重装载时在库程序缓冲区中发生的错误 如果sum(pins)/sum(reloads) ≈ 则库缓冲区的命中率合适 若sum(pins)/sum(reloads)> 则需调整初始化参数 shared_pool_size来重新调整分配给共享池的内存量

　

　 数据字典缓冲区的调整

　

　数据字典缓冲区包含了有关数据库的结构 用户 实体信息 数据字典的命中率 对系统性能影响极大 数据字典缓冲区的使用情况记录在动态性能表v$librarycache中 可通过查询该表来了解其活动情况 以决定如何调整 Select sum(gets) sum(getmisses) from v$rowcache; Gets列是对相应项请求次数的统计 Getmisses 列是引起缓冲区出错的数据的请求次数 对于频繁访问的数据字典缓冲区 sum(getmisses)/sum(gets)< %～ % 若大于此百分数 则应考虑增加数据字典缓冲区的容量 即需调整初始化参数shared_pool_size来重新调整分配给共享池的内存量

　

　 缓冲区高速缓存的调整

　

　用户进程所存取的所有数据都是经过缓冲区高速缓存来存取 所以该部分的命中率 对性能至关重要 缓冲区高速缓存的使用情况记录在动态性能表v$sysstat中 可通过查询该表来了解其活动情况 以决定如何调整

　

　Select name value from v$sysstat

　

　where name in ( dbblock gets consistent gets physical reads );

　

　dbblock gets和consistent gets的值是请求数据缓冲区中读的总次数 physical reads的值是请求数据时引起从盘中读文件的次数 从缓冲区高速缓存中读的可能性的高低称为缓冲区的命中率 计算公式

　

　Hit Ratio= (physical reds/(dbblock gets+consistent gets))如果Hit Ratio< %～ % 则应增大db_block_buffers的参数值 db_block_buffers可以调整分配给缓冲区高速缓存的内存量 即db_block_buffers可设置分配缓冲区高速缓存的数据块的个数 缓冲区高速缓存的总字节数=db_block_buffers的值db_block_size的值 db_block_size 的值表示数据块大小的字节数 可查询 v$parameter 表 select name value from v$parameter where name= db_block_size ; 在修改了上述数据库的初始化参数以后 必须先关闭数据库 在重新启动数据库后才能使新的设置起作用

　

　◆ 调整磁盘 I/O

　

　磁盘的I/O速度对整个系统性能有重要影响 解决好磁盘I/O问题 可显著提高性能 影响磁盘I/O的性能的主要原因有磁盘竞争 I/O次数过多和数据块空间的分配管理

　

　为Oracle数据库服务器创建新文件时 不论是表空间所用的数据文件还是数据事务登录所用的日志文件 都应仔细考虑数据库服务器上的可用磁盘资源 如果服务器上有多个磁盘 则可将文件分散存储到各个可用磁盘上 减少对数据库的数据文件及事务日志文件的竞争 从而有效地改善服务器的性能 对于不同的应用系统都有各自的数据集 应当创见不同的表空间分别存储各自应用系统的数据 并且尽可能的把表空间对应的数据文件存放在不同的磁盘上 这种从物理上把每个应用系统的表空间分散存放的方法 可以排除两个应用系统竞争磁盘的可能性 数据文件 事务日志文件分别存放在不同的磁盘上 这样事务处理执行的磁盘访问不妨碍对相应的事物日志登记的磁盘访问 如果有多个磁盘可用 将两个事物日志成员放在不同的磁盘驱动器上 就可以消除日志文件可能产生的磁盘竞争 应把一个应用的表数据和索引数据分散存放不同表空间上 并且尽量把不同类型的表空间存放在不同磁盘上 这样就消除了表数据和索引数据的磁盘竞争

　

　◆ 调整数据库服务器的回滚段

　

　回滚段是一个存储区域 数据库使用该存储区域存放曾经由一个事务更新或删除的行的原始数据值 如果用户要回滚一个事务所做的改变 那么数据库就从回滚段中读回改变前的数据并使该事务影响的行改变为它们的原状态 回滚段控制着数据库处理事务的能力 因而在数据库成功中起著关键性的作用 不管数据库的其它部分设计得多好 如果它设计得不合理 将会严重影响系统的性能 建立和调整回滚段的原则如下

　

　 分离回滚段

　

　分离回滚段是指单独为回滚段创建一个以上的表空间 使回滚段与数据字典 用户数据 索引等分离开来 由于回滚段的写入与数据和索引的写入是并行进行的 因此将它分离出来可以减少I/O争用 如果回滚段与数据不分离 倘若要某个表空间脱机或撤消 那么在该表空间中的各个回滚段没有全部脱机之前 不能将这个表空间脱机或撤消 而一旦该表空间不可用 则该表空间中的所有回滚段也不能使用 这将浪费所有分配的磁盘空间 所以 独立回滚段可使数据库管理变得容易 回滚段的经常性收缩 使得表空间的自由块更容易形成碎片 分离回滚段可以减少数据库表空间的碎片产生

　

　 创建不同大小的回滚段群

　

lishixinzhi/Article/program/Oracle/201311/18922

为了满足网络应用不断增长的性能需要，我们通常增加新服务器个数，分担业务，提高系统工作性能，即横向扩展。其实也可以通过提高现有服务器的配置来提高服务器的整体性能，即纵向扩展——因为服务器部件的选配对服务器的性能至关重要。而直接存储数据的硬盘更是影响服务器服务性能的重要一环。

提高服务器性能的方法就是寻找制约服务器性能的瓶颈在哪。不同应用可能存在的瓶颈是不同的，有的要重点考虑处理器、内存，有的要重点考虑硬盘或网络的I/O吞吐能力;那么，在哪些应用环境下需要重点考虑服务器硬盘瓶颈呢

通讯服务器(messaging/E-mail/VOD):快速的I/O是这类应用的关键，硬盘的I/O吞吐能力是主要瓶颈;

数据仓库(联机事务处理/数据挖掘):大型商业数据存储、编目、索引、数据分析，高速商业计算等，需要具有良好的网络和硬盘I/O吞吐能力;

数据库(ERP/OLTP等):服务器运行数据库，需要具有强大的CPU处理能力，大的内存容量来缓存数据，同时需要有很好的I/O吞吐性能;

其他应用:应用集中在数据查询和网络交流中，需要频繁读写硬盘，这时硬盘的性能将直接影响服务器整体的性能。

影响硬盘的因素

谈到硬盘的指标参数，首先就应提到硬盘的接口标准。当今主流硬盘的接口界面有两种:EIDE和SCSI，当然此外还有IEEE 1394接口、USB接口和FC-AL(FibreChannel-Arbitrated Loop)光纤通道接口的产品，但是很少见。现在几乎所有的微机普遍采用基于Ultra DMA/33/66/100标准的IDE接口的硬盘，它的优势在于能提供较低价格，普及率很高。

同时，也有部分低端服务器采用了IDE硬盘，目前，几乎所有服务器主板都集成了IDE控制器，但在中高端服务器中还只是普遍用来连接低速外设IDE光驱，而硬盘一般采用SCSI接口标准，如浪潮英信服务器就普遍采用了Ultra160 SCSI硬盘，提供更高的硬盘吞吐能力。SCSI接口硬盘有着极低的CPU占用率、支持更多的设备和在多任务下工作的优势明显等优点，更适合于服务器应用的需求，当然SCSI硬盘价格要高得多。

然而，硬盘的数据传输系统之瓶颈不在于PCI总线或是接口速率上，而在硬盘本身，这是由硬盘机械部分与结构设计等诸多因素造成的。

衡量硬盘的指标

衡量硬盘性能的指标主要包括:

主轴转速

主轴转速是一个在硬盘的所有指标中除了容量之外，最应该引人注目的性能参数，也是决定硬盘内部传输速度和持续传输速度的第一决定因素。如今硬盘的转速多为5400rpm、7200rpm、10000rpm和15000rpm。从目前的情况来看，10000rpm的SCSI硬盘具有性价比高的优势，是目前硬盘的主流，而7200rpm及其以下级别的硬盘在逐步淡出硬盘市场。

内部传输率

内部传输率的高低才是评价一个硬盘整体性能的决定性因素。硬盘数据传输率分为内外部传输率;通常称外部传输率也为突发数据传输率(Burstdata Transfer Rate)或接口传输率，指从硬盘的缓存中向外输出数据的速度，目前采用Ultra 160 SCSI技术的外部传输率已经达到了160MB/s;内部传输率也称最大或最小持续传输率(Sustained Transfer Rate)，是指硬盘在盘片上读写数据的速度，现在的主流硬盘大多在30MB/s到60MB/s之间。由于硬盘的内部传输率要小于外部传输率，所以只有内部传输率才可以作为衡量硬盘性能的真正标准。

单碟容量

除了对于容量增长的贡献之外，单碟容量的另一个重要意义在于提升硬盘的数据传输速度。单碟容量的提高得益于磁道数的增加和磁道内线性磁密度的增加。磁道数的增加对于减少磁头的寻道时间大有好处，因为磁片的半径是固定的，磁道数的增加意味着磁道间距离的缩短，而磁头从一个磁道转移到另一个磁道所需的就位时间就会缩短。这将有助于随机数据传输速度的提高。而磁道内线性磁密度的增长则和硬盘的持续数据传输速度有着直接的联系。磁道内线性密度的增加使得每个磁道内可以存储更多的数据，从而在碟片的每个圆周运动中有更多的数据被从磁头读至硬盘的缓冲区里。

平均寻道时间

平均寻道时间是指磁头移动到数据所在磁道需要的时间，这是衡量硬盘机械性能的重要指标，一般在3ms～13ms之间，建议平均寻道时间大于8ms的SCSI硬盘不要考虑。平均寻道时间和平均潜伏时间(完全由转速决定)一起决定了硬盘磁头找到数据所在的簇的时间。该时间直接影响着硬盘的随机数据传输速度。

缓存

提高硬盘高速缓存的容量也是一条提高硬盘整体性能的捷径。因为硬盘的内部数据传输速度和外部传输速度不同。因此需要缓存来做一个速度适配器。缓存的大小对于硬盘的持续数据传输速度有着极大的影响。它的容量有512KB、2MB、4MB，甚至8MB或16MB，对于视频捕捉、影像编辑等要求大量磁盘输入/输出的工作，大的硬盘缓存是非常理想的选择。

知道了服务器硬盘的性能指标，下一步自然要依此选择出适合具体应用的服务器硬盘，以提高系统的工作性能。

选用高性能硬盘

由于SCSI具有CPU占用率低，多任务并发操作效率高，连接设备多，连接距离长等优点，对于大多数的服务器应用，建议采用SCSI硬盘，并采用最新的Ultra160 SCSI控制器;对于低端的小型服务器应用，可以采用最新的IDE硬盘和控制器。确定了硬盘的接口和类型后，就要重点考察上面提到的影响硬盘性能的技术指标，根据转速、单碟容量、平均寻道时间、缓存等因素，并结合资金预算，选定性价比最合适的硬盘方案。

RAID技术

冗余磁盘阵列RAID系统提供了比通常的磁盘存储更高的性能指标、数据完整性和数据可用性，尤其是在当今面临的硬盘I/O总是滞后于CPU性能的瓶颈问题越来越突出的情况下，RAID解决方案能够有效地弥补这个缺口。

依据磁盘阵列数据不同的校验方式, RAID技术分为不同的等级(RAID Levels)，各有不同的技术特点，读者可以参考有关手册进行选用。

为了更好地提高硬盘的I/O性能，推荐采用RAID技术，根据应用的特点，把被频繁访问读写的硬盘做成RAID0或RAID1、RAID5;目前，在低端服务器可采用IDE RAID，如浪潮英信NP200;而在中高端服务器，建议采用SCSI RAID控制器，并注意RAID控制器有关技术指标，如CPU类型、通道类型和数目、缓存数量、有无电池后备等;需要注意的是:主板集成的RAID控制器由于本身没有硬盘控制器，而占用了主板上的SCSI硬盘控制器，需要耗费更多的主处理器时间，会使服务器的处理能力受到影响。

热拔插技术

除了从性能指标上评价硬盘，还要考虑到硬盘的故障率、平均无故障运行情况和易维护性。在具体的应用中，首先应选用寿命长、故障率低的硬盘，可降低故障出现的几率和次数，这牵扯到硬盘的MTBF(平均无故障时间)和数据保护技术，MTBF值越大越好，如浪潮英信服务器采用的硬盘的MTBF值一般超过120万小时，而硬盘所共有的SMART(自监测、分析、报告技术)以及类似技术，如seagate和IBM的DST(驱动器自我检测)和DFT(驱动器健康检测)，对于保存在硬盘中数据的安全性有着重要意义。

另外，一旦硬盘损坏，应考虑如何保证数据不丢失，并且减少服务器的宕机时间。 RAID技术可以用来保证数据的可靠性和安全性，通过硬盘的热拔插技术可以保证在更换或维修硬盘的同时，服务器仍然能正常运行可用。目前热拔插技术在中高档服务器中非常普遍，一直也被作为服务器档次的一个重要标志。一般在服务器中采用的热拔插技术的部件有硬盘、电源、风扇、PCI插槽等，而SCSI硬盘也有专门支持热拔插技术的SCA2接口(80-pin)，与SCSI背板配合使用，就可以

常见的性能测试方法有以下几种：

　　1．负载测试

　　在这里，负载测试指的是最常见的验证一般性能需求而进行的性能测试，在上面我们提到了用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下的性能表现。我们对负载测试可以有如下理解：

　　（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。

　　（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。

　　2．压力测试

　　压力测试是为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。

　　例子：负载测试关心的是用户规则和需求，压力测试关心的是软件系统本身。对于它们的区别，我们可以用华山论剑的例子来更加形象地描述一下。如果把郭靖看做被测试对象，那么压力测试就像是郭靖和已经走火入魔的欧阳峰过招，欧阳锋蛮打乱来，毫无套路，尽可能地去打倒对方。郭靖要能应对住，并且不能丢进小命。而常规性能测试就好比郭靖和黄药师、洪七公三人约定，只要郭靖能分别接两位高手一百招，郭靖就算胜。至于三百招后哪怕郭靖会输掉那也不用管了。他只要能做到接下一百招，就算通过。

　　思考：

　　我们在做软件压力测试时，往往要增加比负载测试更多的并发用户和交易，这是为什么？

　　3．并发测试

　　验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。

　　4．基准测试

　　当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。

　　5．稳定性测试

　　“路遥知马力”，在这里我们要说的是和性能测试有关的稳定性测试，即测试系统在一定负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或者说是需要时间积累才能达到能够度量的程度。为什么会需要这样的测试呢？因为有些软件的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来；还有客户端和服务器在负载运行一段时间后，建立了大量的连接通路，却不能有效地复用或及时释放。

　　6．可恢复测试

　　测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。

　　提示：每种测试有其存在的空间和目的。当我们接手一个软件项目后，在有限的资源条件下，选择去做哪一种测试，这应该根据当前软件过程阶段和项目的本身特点来做选择。比如，在集成测试的时候要做基准测试，在软件产品每个发布点要做性能测试。

Windows服务器中自带的性能监控工具叫做Performance Monitor；

在开始-运行中输入‘perfmon’，然后回车即可运行。

Monitor本身也是一个进程，运行起来也要占用一定的系统资源。所以你看到的资源的使用量应该比实际的要稍微高一点。这个工具在帮助管理员判断系统性能瓶颈时非常有用；

举个列子来说，今天有个用户抱怨说他们项目组的服务器（这是一台虚拟机）运行起来非常慢，但也不知道具体问题出在什么地方。任务管理器里显示CPU和内存的使用量都不算高，但服务器的相应就是非常慢；

Monitor，让其运行一段时间后（因为参考平均值会比较准确），发现average disk queue的值比较高，这就说明物理服务器的硬盘负荷太重，I/O操作的速度跟不上系统的要求。关掉虚拟机，将其转移到另一台硬盘负载比较小的主机上，再打开虚拟机。

分析性能情况

1、内存泄露判断

虚拟内存字节数（VirtualBytes）应该远大于工作集字节数（Workingset），如果两者变化规律相反，比如说工作集增长较快，虚拟内存增长较少，则可能说明出现了内存泄露的情况。

对于Workingset、Private Bytes、Available bytes这些计数器，如果在测试期间内数值持续增长，而且测试停止后位置在高水平，则也说明存在内存泄露。

Windows资源监控中，如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Available

bytes计数器的值持续降低，则很可能存在内存泄漏。

2、CPU使用情况

一般平均不要超过70%，最大不要超过90%（好：70% 、坏：85%、 很差：90%）。

3、tps（每秒处理事务的数量，在SOAPUI中进行统计）

一般在10-100，不同应用程序具体值不同。