性能测试常见问题

 

名词解释

 

性能测试FAQ

 

1. 性能测试的基本过程是什么？

 

2. 如何准备测试环境？

 

3. 准备环境时，由于条件限制，机器系统硬件环境可能不同，机器硬件的cpu主频，单双核，硬盘转速等对性能测试的影响情况如何，在准备测试中哪些因素可以较少考虑或者忽略？

 

4. 我们的机器本身会启很多自动服务，其对性能的影响如何？

 

5. 测试过程中应该收集哪些数据？应该怎么获得？

 

6. 是否打开cache，对性能测试有什么影响？

 

7. 系统缓存对性能测试有什么影响，如何减少这种影响？

 

8. 如何选择压力工具？

 

9. 如何准备压力词表？

 

10. 压力测试中，每组压力执行多长时间合适？

 

11. 如何配置压力？

 

12. 什么是极限，怎么知道已经到了极限？

 

13. vmstat 和 iostat 各项指标有什么含义，怎么用于分析？

 

14. 如何评估测试结果的正确性和合理性？

 

15. 网卡带宽对压力测试有什么影响？

 

16. timewait 对服务极限压力有何影响？

 

性能测试Tips (来自于大家的经验收集)

 

1．测试前需要对测试结果进行预估

 

2. 测试过程中对测试环境，以及测试数据的记录应该清晰统一。

 

3. 当对要测试的模块或者系统不熟悉时，应该提前做一些背景了解。

 

性能测试实例

 

附

 

性能测试常用工具简介

 

起压工具

 

数据采集工具

 

其他工具

 

相关文章

 

 

 

 

 

 

名词解释

 

 

 

用户态数据：指从模块角度看到的反映系统性能的一些数据，如平均响应时间等。通常使用用户态数据直接衡量模块和集群的极限压力。

 

 

 

系统态数据：指从系统角度看到反映系统性能的一些数据，比如cpu占用率等。通常系统态数据来衡量系统负载和分析性能瓶颈，不直接用它来作为评估极限性能的标准。

 

 

 

性能测试FAQ

 

1. 性能测试的基本过程是什么？

 

性能测试，大概分为以下过程：

 

l  测试计划制定

 

确定性能测试的目标，采用的测试方法等。

 

 

 

通常性能测试可能有以下目标：

 

                        i.              对架构升级，或者性能升级进行评估测试，摸清极限压力。通常这类测试更加关注用户态的数据。

 

                      ii.              性能升级前或升级进行中的调研，旨在摸清模块性能方面存在的问题，寻找优化的的切入点。通常这类测试更加关注系统态的数据。

 

 

 

当然这里提到的是两个主要的方向，实际的性能测试，可能有特性化的需求，比如测试某个模块的 并发性。

 

 

 

对于测试方法，确定时大概需要考虑以下几个方面：

 

1.       测试目标

 

性能测试的目标决定了性能测试的方方面面，比如是测单机，单模块的极限性能，还是测一个子系统的极限性能。这决定了采用测试方法，以及机器的准备，一个子系统的测试，理想情况，需要按照线上的部署方式，完成各各模块在测试环境的部署。而单机，单模块的测试，则对环境要求没有那么严格，但需要考虑测试机器CPU，内存，以及机器上运行的其他程序，对测试的影响。

 

 

 

2.       环境设计

 

包括以下几个方面：

 

1.       需要几台机器，各各模块如何部署。

 

2.       对机器的硬件(CPU, 内存)，系统(内核，其他软件)要求。

 

3.       使用的测试方法和准备收集的数据。

 

关于测试方法，以及数据采集，针对不同的性能测试需求，都有不同的方法。后面会有针对性的说明。

 

 

 

l  测试实施

 

按照测试计划完成性能测试。并收集重要的数据以供后续的数据分析。

 

 

 

l  测试数据分析

 

对测试过程得到的数据进行分析。得到 模块 或者 系统 在性能方面的指标，或者发现 模块 或 系统 在性能方面的问题。

 

 

 

l  完成测试报告

 

通过测试报告，可以清晰的说明性能测试的情况，可用作评审，以及其他相关测试工作的参考。

 

 

 

2. 如何准备测试环境？

 

       根据测试类型的不同，测试环境的准备也会有一些不同。

 

一般的极限压力测试，要求测试环境与线上环境尽可能一样，包括软硬件环境。硬件环境主要指机型（dell还是hp）与配置（内存，cpu）应该相当；软件环境包括 基础库，线上与该模块一起部署在一台机器的其他模块，以及这些模块应有的压力。

 

       进行单模块的性能测试一般则要求环境里面影响因素极可能少，一般只运行被测试程序。

 

       进行对比测试，一般是相同硬件，不同程序实现的测试，或者相同程序，不同硬件的测试。则要求两个对比环境中，除了需要对比的因素，其他条件尽可能相同，词表和测试方法，也应该保持一致。

 

3. 准备环境时，由于条件限制，机器系统硬件环境可能不同，机器硬件的cpu主频，单双核，硬盘转速等对性能测试的影响情况如何，在准备测试中哪些因素可以较少考虑或者忽略？

 

   机器环境中常见的一些因素以及影响情况如下：

 

 

 

Ø    CPU主频及单双核

 

CPU主频及单双核主要影响CPU密集型的业务的性能。同等压力下，较高主频的CPU一般处理请求的时间短，而较低主频的CPU处理请求的时间长。

 

目前机器的主流CPU 双路双核和双路四核 根据主频可以分为Xeon3.0G  2.8G

 

Ø  内存大小

 

内存大小对业务性能影响较为明显，大内存的机器，其系统可用cache较大，可加载到内存中的数据较多，可以明显减少系统I/O，大大缩短响应时间。

 

目前单条容量2G的内存比较多，机器总内存8G和16G居多。测试前可以通过free命令查看

 

Ø  磁盘转数

 

我们现有磁盘的转速基本都是10k/min，15k/min的磁盘较少，除非特殊情况，一般可以忽略该配置。

 

Ø  磁盘容量

 

常见的磁盘容量有73GB、146GB、300GB。较大的磁盘容量单盘片数据密度较高，磁头寻道时间较短，磁盘性能较好。

 

Ø  磁盘接口

 

常见磁盘接口有SCSI、SATA、SAS，其中以SAS接口的磁盘性能最好。

 

Ø  预读RA值

 

系统预读，对于随即读为主的业务，由于读取的数据存储较为分散，建议调小该预读值；相反以顺序读为主的业务，应该调大该值。

 

在随机度为主的业务中，调小该值可以明显看到iostat统计到的r/s值明显降低，vmstat统计到的bi值同时降低。

 

Ø  RAID级别

 

现有机器的RAID级别只有两种：RAID1+0和RAID5，RAID1+0的I/O性能好于RAID5

 

Ø  RAID读写比率

 

只有HP的RAID卡有读写比率的概念，Dell的RAID卡没有这个概念。

 

Ø  Swap分区

 

Swap分区对系统性能影响较小，可以忽略。大小可以通过free查看

 

Ø  磁盘碎片

 

       对于ext2文件系统来说，磁盘块的分配会根据一定的算法尽量使得同一目录下的文件放在同一块组，即尽量保持连续性。多线程的随机读写会导致文件在磁盘上的存放连续性较低。磁盘连续性越低，导致磁盘寻道频繁，降低了系统的I/O性能。磁盘连续性可以通过plblk工具查看。

 

 

 

4. 我们的机器本身会启很多自动服务，其对性能的影响如何？

 

机器上启动的服务如下面所列：

 

hwinfo: 硬件信息插件 每天一次 ，cpu计算型服务

 

update: 自更新插件 触发式    （插件网络下载）

 

system-mon: 系统信息插件（包括vmstat和iostat） 每10分钟一次 ，cpu计算型服务、由于会写日志，所以会有少量IO。

 

mysql-mon: 数据库监控插件（只有几个产品线部署了） 每10分钟一次 ，读取内存中的一些信息，有一些写日志的操作，可能会有少量IO。

 

sys_agent.sh:  sa的获取资产信息的程序，启动时运行一下。

 

磁盘监控:  大概每半小时上线上服务器df一下（其它服务器上）

 

core监控:  大概每半天，上线上find core一下（会制定home下的工作目录，其它服务器上）

 

服务监控: 每20秒会向模块发出一次监控请求（其它服务器上）

 

5. 测试过程中应该收集哪些数据？应该怎么获得？

 

一般而言，需要收集的数据分为两类：用户态数据和系统态数据。用户态数据直接衡量模块和集群的极限压力；而系统态数据来衡量系统负载和分析性能瓶颈。

 

用户态关心的数据包括：

 

A.     请求平均响应时间

 

B.      最大响应时间

 

C.      Overflow数或超时数

 

D.     N倍平均响应时间请求比例

 

其中， n倍平均响应时间比例是指在所有请求中响应时间超过n倍平均响应时间的请求比例有多大，这个参数比最大响应时间能更好的描述响应时间的分布状态，因为最大响应时间受某一次特殊状态的影响很大。n的取值可以按照所测试系统的不同选择3倍、5倍或者更多。请求超时数也是一个关键的指标，一般认为出现超时情况，即认为性能达到瓶颈，不能稳定服务。

 

 

 

一般而言，用户态的数据都可以从程序的输出log中得到。一些压力工具的日志也可以作为参考。

 

 

 

系统态数据

 

系统态数据主要用来衡量系统负载和分析性能瓶颈，不直接用它来作为评估极限性能的标准，一般我们比较关心的常见系统态指标分为CPU相关，I/O相关，网络相关等。

 

       CPU相关： us sys id wa等

 

       I/O相关：  bi bo r/s w/s await等

 

       网络相关： rxpackets txpackets rxbytes txbytes等。

 

      

 

系统态参数一般可以通过linux自带的工具可以获取。如cpu、io相关参数可以通过vmstat、iostat命令观察到，其中iostat的util%表示io请求队列非空的时间的比例，当达到100%时，系统的io就已经达到饱和。网络相关参数可以通过sar -n DEV 1 10命令获取，后面两个数字 1 表示统计的时间间隔，10表示统计次数。这几个命令基本上可以满足对系统态参数的观察，具体使用方法参考man手册（具体含义请参考 条目13）。

 

 

 

6. 是否打开cache，对性能测试有什么影响？

 

我们目前的系统中通常都有cache模块。在后端是IO型的服务，前端有cache的模式下，前端cache 打开与否，命中率都会对后端IO型服务得到的测试指标有影响。以 BS 的测试为例，AS 通常都会对BS 的结果有一定的cache，在测试中会发现，AS cache开启的情况的到BS的极限压力会低于开启AS Cache时得到的BS极限压力。造成这种差异的原因主要为：as端cache的引入，使落到bs的请求更为的随机，而对系统cache的利用更加低效，从而极限压力也受到影响。

 

所以，如果仅仅是想针对bs进行基础性能回归，或者bs进行性能调优过程中的测试，可以暂时不考虑as cache带来的影响，而在进行bs 极限性能的测试，则必须考虑as cache的影响，因为极限性能的指标将直接作为线上服务部署的依据。

 

 

 

7. 系统缓存对性能测试有什么影响，如何减少这种影响？

 

   系统缓存指操作系统使用一部分未分配内存用来对IO操作进行缓存，从而优化IO。操作系统的这种行为对 数据量较小，访问存在一定的连续性 的IO型服务有非常大的影响，可能导致性能测试的数据不准确，通常是测试结果优于实际结果。为了减少这种影响，需要注意：

 

       1. 词表的选取应该有一定的数量，现有的压力工具通常都会循环压力，压力词表太小，在循环之后，基本上都重磁盘cache，性能远远高于正常需要磁盘IO的访问。 而词表的顺序上，应该尽量模拟线上服务的访问特性，过于连续，则得到的性能测试结果相对真实情况偏好；过于随机，则得到的性能测试结果相对真实情况偏差。

 

       2. 对数据量较小的服务，相同的数据压过多次后，也受磁盘cache的影响比较大，每次新起压力应对磁盘cache进行清理。 清理的方法有：重启系统， 拷贝大文件，使用系统组提供的工具。

 

8. 如何选择压力工具？

 

对于直接对web server起压力进行的测试，目前公司常用的压力工具有myab, myabc, http_load 等。myab在baidu的qa部门被广泛使用，但在测试过程中发现myab在压力较高的情况下（500次每秒以上），不能稳定地输出压力。http_load在baidu也有所应用，它能输出的压力最高有1000次每秒，且相对很稳定。而http_load是将要发送的http请求全部加载到内存后，随机选择请求进行发送，而myab是按照词表文件顺序依次发生请求。因此myab用来测cache命中率较准，而http_load的cache命中率相对会低一些，因为随机发送和线上的实际情况并不一样。

 

另外，对于直接发向web server 的性能测试，需要注意配置请求头的接受压缩——是否进行压缩对前端机器的性能影响比较大。

 

      

 

对于直接对某个模块起压力，可以使用 CerBerus，该工具为模块级的压力工具，可以模拟模块之间的网络请求，支持并发，大压力和灵活的构造请求数据。而stl 提供的pfmtest 也可以对模块进行压力测试，它支持比较灵活的压力控制，但需要根据不同的模块实现接口函数。

 

9. 如何准备压力词表？

 

压力词表一般而言，希望尽可能模拟线上用户请求的访问特性，所以通常从线上日志(Web Server) 获得。针对的具体的不同的测试，也可以构造一些压力词表。例如comdb的测试中，由于数据量大，访问离散，测试即采用随机数据ID进行。

 

10. 压力测试中，每组压力执行多长时间合适？

 

       每组压力执行时间并没有严格的规定，通常是只要足以得到 稳定 的性能表现记录即可。也不宜进行的太久，否则整个测试时间较长，影响效率。

 

       以BS的测试为例，一般习惯，进行30分钟左右的压力测试，看系统是否稳定，然后统计稳定后15分钟的数据。

 

11. 如何配置压力？

 

       压力的配置可以参考该模块历史的测试情况，新模块可以根据设计的性能指标，或者其他类似模块的性能情况。 对于升压测试而言，一开始压力可以不用太大，逐步递增，最后获得模块或者系统能能够承受的最大压力。

 

12. 什么是极限，怎么知道已经到了极限？

 

STL对极限压力有一个抽象的标准：正常线上服务不受影响。意义为，超过这个压力，服务就开始出现一些异常，比如出现一定数量的 超时，拒绝连接等。

 

 

 

13. vmstat 和 iostat 各项指标有什么含义，怎么用于分析？

 

vmstat 主要关注r b bi bo id wa几个指标。

 

r  ready的进程数，也就是还没有得到cpu的进程数，一旦得到cpu，那么该进程马上可以执行，如果该值过大（是否过大的标准是以你的程序会起几个进程为准，没有一个固定的值），那说明你的程序起的进程太多，建议一下降低进程个数，过多的进程切换是造成性能下降的原因之一。

 

b block的进程数，对于IO操作而言，主要是等待IO完成而被block的进程数，该值同样没有一个固定的标准值，相对于你的程序，这个值也不要太大。

 

bi 读的速度，单位是KB/s，顺序读情况下hp在160MB/s左右，dell在200MB/s左右。随机读两者相差不大。

 

bo 写的速度，单位是KB/s，顺序写时，hp的机器在不同的raid卡cache读写比率下正常值是不同的（bi值不受raid卡cache读写比率的影响），read/write在25/75时最好，写的速度可以到150~160MB/s；0/100时与25/75差别不大，也能到150~160左右；50/50速度在 100~120MB/s； 75/25 在100MB/s一下；100/0则在30~50MB/s之间。dell的机器一般都在180MB/s以上，最高可以到200MB/s以上。

 

id 是当前cpu处于idle的时间比例，这个也没有一个固定的标准值，该值过高说明当前cpu没有利用完全，还有继续压榨的能力

 

wa 当前cpu处于等待IO的时间比例，该值同样没有固定的标准值，如果这个值太高，比方说超过60%，那就要看看当前系统中是不是存在IO拥塞现象。

 

 

 

iostat主要关注r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await %util指标。

 

r/s 每秒读请求次数，这个值通常会跟avgrq-sz一起观察，avgrq-sz大则有可能r/s比较小

 

w/s 每秒写请求次数，这个值通常会跟avgrq-sz一起观察，avgrq-sz大则有可能w/s比较小

 

rkB/s 这个指标跟vmstat的bi值通常应该是很接近的

 

wkB/s 这个指标跟vmstat的bo值通常应该是很接近的

 

avgrq-sz 每个请求平均大小，单位是扇区数，一般在200~400之间算是正常和理想的状态，如果这个值比较小，比方说只在100左右，说明太多的IO请求没有被合并，或者大的IO请求被“打散”，在写操作时，过多小的请求会造成磁盘磁头的频繁移动，降低IO性能。

 

avgqu-sz 平均请求队列长度，这个值在正常的系统中不应超过113太多，如果在200左右，甚至上千那说明发生了IO拥塞，而系统还在向IO请求队列中放请求（有一个例外是在执行sync,fsync操作时，该值到达最大值8192是正常的）

 

await 单位是毫秒，不应超过两位数，几百甚至上千都是不可接受的。

 

%util 尽可能的让该值达到100%，否则说明IO能力没有完全被利用。

 

14. 如何评估测试结果的正确性和合理性？

 

       在测试前，应该对测试结果有一个初步的估计，比如，性能（IO/CPU）应该是提升，还是降低，大概幅度会有多少。这样当测试结果与预估偏差极远时，很可能测试的过程或者方法是有问题的。

 

       如果是已有模块，可以参考改模块历史的测试数据。看变化是否合理。

 

       如果是新模块，可以参考类似模块的性能测试数据。

 

       对数据本身，可以做一些逻辑上的相互验证，比如：一般而言，idle应该随压力增加而降低，压力升高，idle反而变高，有可能是大部分的请求都命中了系统cache，此时测试数据已经不准确。

 

 

 

15. 网卡带宽对压力测试有什么影响？

 

对于压力较大，或者数据流量较大的服务，比如空间图片服务，可能会出现由于网卡跑满，而压力上不去的现象，此时机器负载较为正常，但压力上不去。这对于测试环境，这是一个比较容易的现象。 比如 zjm机房的出口是百兆的，很容易压满。此时需要根据情况，将压力分布开。

 

当然也有一些模块，网卡本身就是瓶颈。了解网卡带宽对压力的影响，也有助于在分析时得出正确的判断。

 

 

 

16. timewait 对服务极限压力有何影响？

 

对于常见的CS关系的网络交互服务，当client 主动close，会进入timewait 状态，但此时socket 仍然被占用，无法回收，这一请情况可能会影响 短链接的并发压力，因为大量的socket处于timewait 状态会使client 句柄耗尽。 一般情况，短连接压倒 400~500 就已经不稳定了。

 

 

 

缓解这一问题的，一般而言，有下面四种：

 

1. 逻辑实现上，尽量 server 端主动关闭。

 

2. 设置 SO_LINGER close.

 

    这是一种不太体面的做法， 因为它触发的不是一个正常的结束。并且抹杀了TIME_WAIT 状态存在的意义： 网络上可能还有数据在传送，若此socket的替身出现，会收不到该收的包。

 

3. 打开端口复用和快速回收

 

4. 修改系统timewait 时间

 

       上面三个是应用层的方法，这是一个需要修改系统kernel的方法。

 

性能测试Tips (来自于大家的经验收集)

 

1．测试前需要对测试结果进行预估

 

进行测试前，最好能对测试的结果有一个大概的预估。这样才测试结果出来后，可以有一个大概的对比参考，有助于对测试结果的验证，可以较早的发现一些由于测试方不合理导致的问题。 预估可以根据 机器的特性； 如果是已经存在的模块，可以参考该模块已有的测试结果；如果是新模块，可以参考相似特性的模块的性能测试结果。

 

 

 

2. 测试过程中对测试环境，以及测试数据的记录应该清晰统一。

 

重视测试数据的记录，注意记录测试环境、测试过程，可以采用统一的测试报

 

告模板；不然最后会搞得很混乱，事后分析数据时不清楚当时的情况了

 

 

 

3. 当对要测试的模块或者系统不熟悉时，应该提前做一些背景了解。

 

比如这个模块（或者某个系统， 比如MySQL）的性能特性，是IO型，还是CPU性，历史的测试情况，测试方法。测试中应该注意的一些问题，可以向有相关经验的工程师了解，能够很大程度上帮助测试的顺利进行。

 

性能测试实例

 

下面将以几个性能测试的实例，说明性能测试的基本过程。

 

 

 

1. Image BS 性能升级测试

 

       需求场景：

 

       对Image BS模块进行性能优化升级，需要测试了解新BS的极限性能，并同时得出性能升级后的整个系统能够承担的流量。

 

      

 

首先，准备测试环境。 由于要测试BS模块的极限性能，希望BS的测试环境能够尽可能的与线上环境类似，在这次测试中，主要考虑两个问题：

 

       A. 机型&配置&软件部署

 

         由于测试重点在于 bs的性能，所以测试环境的设计上，要求bs模块部署的环境与线上完全相同：

 

l  硬件方面包括：

 

机型(CPU)，内存，硬盘，Raid。

 

l  软件方面包括：

 

BS的部署方式， 在本例中，假设一台服务器部署两个BS，两个DI。 应用层cache等配置与线上保持一致。

 

l  数据部署：

 

由于BS属于IO型服务，受数据量的影响很大，因而测试环境的数据需要保证和线上数据量一致。本例两个BS，DI 加载线上一层数据。

 

 

 

       B. 测试环境架构

 

       由于Image BS在线上运行在一个集群之上，通常集群的均衡冗余策略，以及包含cache模块的存在，往往会影响数据的访问情况，从而影响线下测试的准确性。 由于线下的资源优先，通常我们不可能在线下搭建与线上一样的集群，这就要求我们在线下搭建测试环境时，充分考虑集群部署对测试带来的影响。

 

       假设线上前端se机器（部署UI，AS）有8台，BS/DI 机器有 6层*5列。最终的测试环境选择 使用一台机器部署UI，AS； 一台机器部署BS/DI，做这样的环境设计包含了两个前提：

 

       1. AS 向BS 发请求的方式是 一个query每层都需要发检索请求，也即BS的多层本身对BS的访问特性并无影响。

 

       2. 单BS/DI 机器对DI的访问特性带来了较大的影响。包括两方面：

 

              I．在多层的环境下，DI请求将根据数据分布落到各层的DI上，单层的环境下，只会落到一个这一层的DI上。

 

              II．AS对DI的均衡策略为，根据di_id 在层内做hash均衡，然后每DI都可能有一些di的请求。在这种策略下，如果列数减少，意味着DI每次请求需要读取的DI数据变多。

 

              综合上面两中情况，总得来说，每个DI每次需要读取的DI个数变多。 再经过测试后，确认这一情况将会使线下的测试数据表现低于线上真实的表现（也即和我们保守估计的原则一致），并且影响程度在可接受的范围内。认为可以接受。

 

       当然，在资源允许的情况下，最好还是能够按照一层多列的架构进行测试。

 

      

 

       测试环境准备好，可以进行压力测试，在这个环节，主要考虑下面几个问题：

 

       A．测试词表准备

 

              测试词表通常反映了用户的访问特性，所以在极限测试的中，为了尽可能模拟线上的真实情况，尽量使用线上的日志做测试词表。根据压力直接作用的模块不同，可以选取不同的模块的日志。 这里的测试词表从UI日志中取出，但直接作用到Web Server，因为UI与AS为长连接，一对一的关系，所以UI的日志可以认为和AS的日志反映的用户访问特性是一致的。

 

       B．压力方法

 

              做极限性能测试，通常采用升压测试的方法。 压力的设定要考虑测试的目标模块，以及相关模块已知的极限压力。在本次测试中，压力的计算大概按照以下方式：

 

              假设 线上单个 bs 平均压力为 20，那么可以以20为基准， 按照as cache穿透率80%，以及一台机器部署两个bs，反推as 端的压力应该为 200。那么以200为基准，按照一定的步长，比如50，增压，做升压测试，直到得到系统的极限。

 

 

 

       C．摒除cache干扰

 

              在本测试中，cache的影响包含两方面：

 

              1. AS端应用层cache的影响。

 

                     实际线上as cache的命中率平均85%，而as cache的存在会影响到落到bs的请求的访问特性，从而影响bs端的极限压力与真实可支持的极限压力的差异，举例而言，打开cache的情况下，bs能够支持的极限压力也许是打开as cache下测试结果的两倍，因为as cache的存在使bs的访问更加的随机。

 

                     为了避免as cache的影响，在压力词表的选择上，更加需要注意与线上日志的一致程度，以保证as cache的命中率在一个比较正常的值。这是一个需要根据情况调整的过程，也许根据实际测试数据量的差异，还需要对as cache的配置作一定的更改。

 

 

 

              2. BS端系统cache的影响。

 

                     由于进行升压测试，每一小段压力进行完后，需要清除系统cache，或者新的词表，以消除系统cache对测试的影响。 系统cache会使测试值远远优于真实值，很可能出现，压力越高，反而系统反应出来的负载比低压力还低的情况。

 

                     清除系统cache的方法有：拷贝大文件，使用系统组提供的工具，重启机器。

 

 

 

       D．注意数据记录

 

              升压测试的过程中需要做多轮压力，中间需要记录用户态数据，以及系统态数据。在本测试中，用户态数据主要从各各模块的日志中体现，而系统态数据则有专门的工具获得，详见数据获取工具介绍。 需要特别注意的时，由于升压测试需要做多轮测试，多轮测试中产生的日志等记录数据需要妥善保存，并相互区分，以免测试记录相互覆盖，混杂，增加后面做数据分析的困难。

 

 

 

       在测试过程完成后，即对测试数据进行分析。关于极限性能的得到，主要是关注用户态数据，具体而言，在本测试中，即as 对bs读超时的情况，as两次读失败的情况，以及整个检索反应出来的响应时间。得到BS的极限性能之后，由于我们在测试架构的设计上就考虑了对线上系统的模拟，因而，得到线上整个系统能够承受的极限压力也就相对较为容易获得，比如在本测试中，对线上极限压力的反推公式为： (bs极限压力/0.2)*2*线上列数。

 

附

 

性能测试常用工具简介

 

起压工具

 

1.       myab系列

 

web server端的负载工具，多线程，根据词表将压力压到apache 等web server。 其中myabc是 myab的增强版，可以通过xml词表定义http请求头中的各个字段。

 

 

 

2.       CerBerus

 

Cerberus 是一款可模拟任意socket接口的模块级测试工具，可用于模块的性能压力测试，也可用于构造边界输入、进行单元测试。

 

cerberus 根据xml描述的配置文件构造请求数据包的二进制格式，根据xml描述的数据文件构造请求数据包的具体内容。

 

目标用户 ：做单元测试的RD，做模块级测试、接口测试的QA

 

 

 

详情请见：

 

http://com.baidu.com/twiki/bin/view/Main/CerBerus

 

 

 

3.       pmftest

 

pmftest 为 STL开发的压力测试框架。socket接口，在框架上实现与待测试模块的交互接口后，即可对待测模块进行压力测试。 压力控制方面，支持：

 

l  控制在指定压力

 

l  维持在指定超时时间

 

l  维持在指定平均响应时间

 

等多种压力控制模式， 配合stable.sh 脚本，可以一次性测试各种不同压力情况下模块的性能，并统计此期间I/O CPU 等指标。 比较适合做极限压力测试。

 

 

 

详见pfmtest 说明文档 <pfmtest_info.doc>

 

数据采集工具

 

用户态数据可以通过压力工具日志（例如pfmtest）日志 或者 模块日志进行。

 

 

 

系统态数据可以通过下面的一些工具：

 

1. sysinfo.pl

 

       综合记录 vmstat， iostat， mpstat， sar 等数据

 

2. vmstatstat.sh

 

记录 vmstat 信息

 

3. iostatstat.sh

 

记录 iostat 信息

 

 

 

其他工具

 

1. clearcache

 

清空系统缓存的工具，在做受系统缓存干扰大的IO性能测试时，很有用。