性能测试

我们经常会听到性能测试，那个谁谁谁帮我做下性能测试。可是我们对性能测试了解吗？什么叫作性能测试？ 

性能测试是什么

  性能测试是指通过特定方式，对被测系统按照一定策略施加压力，获取系统响应时间、TPS（Transaction Per Second）、吞吐量、资源利用率等性能指标，以期保证生产系统的性能能够满足用户需求的过程。从广泛意义上讲性能测试包括：压力测试、稳定性测试、负载能力测试和可扩展性测试等。在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案。

在知道性能测试概念之后，我们还需要了解以下几个名词的含义：

·命名用户数

  是指在应用系统中注册的所有系统用户

·在线用户数

  是指同时登录应用系统的用户数量

·并发用户数

并发用户数是指系统运行期间同一时刻进行业务操作的用户数量

该数量取决于用户操作习惯、业务操作间隔和单笔交易的响应时间

使用频率较低的应用系统并发用户数一般为在线用户数的5%左右

使用频率较高的应用系统并发用户数一般为主线用户数的10%左右

·交易

业务层面和技术层面两种定义

业务层面交易是指完成一次完整的业务操作，如进行一次查询、转账

技术层面交易是指进行一次应用程序至应用程序、或者应用程序至数据库的系统操作

一般的一笔业务交易由多笔技术交易组成。

根据业务交易的复杂度和系统应用架构的不同，其比例大致为1：2 --1：10

性能测试流程

性能需求分析

　　性能需求分析是整个性能测试工作开展的基础，如果你连性能的需求都没弄清楚，后面的性能测试工具就无从谈起了。

　　在这一阶段，性能测试人员需要与需求人员（客户）、领导及项目相关的人员进行沟通，同时收集各种项目资料，对系统进行分析，确认测试的意图。当然，还需要客户对性能的态度。

　　测试需求分析阶段的主要任务是确定测试策略和测试范围。策略主要根据软件类型以及用户对系统的性能的需求来定，测试范围则主要分析系统的功能模块进行调研与分析。最终确认明确的需求。

性能测试计划

   确定明确的需求之后，我们要做的工作就是制定性能测试计划。对性能测试过程中所有需要工作制定与规划。

测试计划的大体内容：

　　项目的简单背景描述，本次性能测试的需求与目的，性能需求分析的结果是什么。测试环境的准备，需要什么样的软硬件配置，网络状况登录。测试数据的准备，对于某些性能测试是需要事先准备测试数据的。

　　测试的策略，前面进行需求分析的目的是制定测试策略，也就是设计符合需求的测试场景，需要对系统的哪些业务模块进行测试，如何进行？需要设计哪些场景以及设计这些场景的目的。

最后会明确一下人员配备，比如需要开发、DBA、运维都人员的参与协助，性能测试的时间安排。

测试环境搭建

测试环境搭建，分硬件环境与软件环境，硬件环境主要是向上级审批硬件配备，在某些大型性能测试，可能需要公司购置或租用硬件设备来进行。或者是将来原有设置进行调配与重组，这个时候就需要网络工程师的参与或协助。

软件环境的搭建对于开发人员来说应该毫无压力，比如常见的三大环境，微软的windows + IIS+SQL server 2005+.NET平台、windows/linux+tomcat/weblogic+mysql+java 、linux+ apache+mysql+PHP 等环境。当然身为性能测试人员，不仅也需要会搭建软件平台，更需要对每个平台中的部分有比较深入的了解。因为性能测试的分析并不是死盯着系统应用那一层。中间件、数据库、系统、硬件都有可能成为系统的瓶颈。

性能工具的引入

其实走到这一步进才需要引入性能测试工具，我们在日常的工作中往往是先选定好测试工具然后再分析需求，制定计划进行测试。这样我们在做性能需求分析的时候往往会往往会考虑所选的工具是否能实现，无法实现可能就放弃这个需求或改变这个需求。这样以某一工具为基础点做出的性能测试结果可能是不准确的。

工具的引入分为自行开发与引入市面上的现有工具。市面上的现有工具又分为收费与开源免费，各有各的优缺点。我们要做的是对需求进行分析，从成本，购买成本，开发成本，现有开源工具的二次开发成本，人员学习使用成本以及时间成本等。

在这里再强调一点，不是只有压力测试工具属于性能工具，在性能测试过程中所用到的工具都属于性能工具，如测试数据生成工具，性能监控工具等。

测试的执行

　　测试的执行应该是很大范围的一块内容。也就是我在上一节中性能测试架构所提到的内容。用户行为生成-->压力产生器-->用户代理-->测试调度-->系统监控等。 

　　我们所选择的工具如何来实现我们的需求，这个性能测试工程师对引入的有足够的了解。对协议的了解，可能需要编程的能力等。其实好多新手对性能的学习也是从某一工具的使用开始的。

测试结果的分析

　　这里再重复一次，测试工具只是提供多种不同的数据揭示和呈现方法而已。工具本身并不能帮我们进行性能结果的分析。

　　对于性能测试结果的分析，这个需要性能测试工程师对整个被测环境的各种软硬件都要有深入的了解。当然，在这个过程中我们往往需要各个岗位人员的协助，开发人员、DBA、运维等。致力成为一位资深的性能测试工程师要走路还很长。

软件硬件配置调整与优化

　　说的简单点这个环节属于系统调优阶段。这一项不是一个必须的环节。这个要看你本次性能测试的需求与目的。如果只是为了验证系统的能力的话。在分析完测试结果后就可以出性能测试报告了。

　　对于我们测试人员来说，我们对一个系统进行功能测试的目的是验证系统功能是否是符合需求并可用的，但发现了缺陷之后是需要对缺陷进行跟踪和修复的，并不是把发现的缺陷写在报告里就完事的。当然，功能缺陷与性能缺陷存在着本质的缺陷。如果在性能测试过程中发现不满足需求的缺陷，进行调优是一个不可缺少的过程。

 　　如果要对系统进行调优的话，测试执行、结果分析、系统调优将会形成一个循环持续的过程。直到满足客户的需求为止。

性能测试关键指标

软件性能测试的目的主要有以下三点：

1、 评价系统当前性能，判断系统是否满足预期的性能需求。

2、 寻找软件系统可能存在的性能问题，定位性能瓶颈并解决问题。

3、 判定软件系统的性能表现，预见系统负载压力承受力，在应用部署之前，评估系统性能。

而对于用户来说，则最关注的是当前系统：

1、 是否满足上线性能要求？

2、 系统极限承载如何？

3、 系统稳定性如何？

       因此，针对以上性能测试的目的以及用户的关注点，要达到以上目的并回答用户的关注点，就必须首先执行性能测试并明确需要收集、监控哪些关键指标，通常情况下，性能测试监控指标主要分为：资源指标和系统指标，如下图所示，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关。

性能测试监控关键指标说明

1、  资源指标

CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。

内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。

磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。

网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。

2、  系统指标：

并发用户数：某一物理时刻同时向系统提交请求的用户数。

在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。

平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。

事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务，如下图所示：

单位时间内系统可以成功完成多少个定义的事务，在一定程度上反应了系统的处理能力，一般以事务成功率来度量，计算公式如下所示：

超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的比率。

如何监控关键指标

1、  资源指标监控

主要针对各服务器系统平台（Windows、Linux、Unix等）资源使用进行监控。

可以使用系统自带的性能监控工具或者第三方工具进行监控，如Windows系统自带的“系统性能监视器”，如下图所示：

Linux系统下，free、vmstat、sar、iostat等命令监控内存、CPU、磁盘IO等的使用情况，如下图所示：

第三方监控工具，如spotlight，spotlight是quest公司开发的一款可以针对多种系统平台及数据库进行监控的可视化工具，如下图所示：

Nmon是IBM提供的监控AIX和Linux系统资源的免费工具，可以对收集的资源信息通过Excel进行统计分析形成直观的统计图，如下图所示：

 （为了配合性能测试，我们往往需要将一个时间段内系统资源消耗情况记录下来，这时可以使用命令在远程窗口执行命令：

./nmon/ nmon_x86_rhel5  -f -N -m /nmon/log  -s 30 -c 120
其中各参数表示：
  -f 按标准格式输出文件：<hostname>_YYYYMMDD_HHMM.nmon
  -N include NFS sections
  -m 切换到路径去保存日志文件
  -s 每隔n秒抽样一次，这里为30
  -c 取出多少个抽样数量，这里为120，即监控=120*(30/60/60)=1小时
    根据小时计算这个数字的公式为：c=h*3600/s，比如要监控10小时，每隔30秒采样一次，则c=10*3600/30=1200

该命令启动后，会在nmon所在目录下生成监控文件，并持续写入资源数据，直至360个监控点收集完成——即监控1小时，这些操作均自动完成，无需手工干 预，测试人员可以继续完成其他操作。如果想停止该监控，需要通过“#ps –ef|grep nmon”查询进程号，然后杀掉该进程以停止监控。

生成结果文件

     通过后台监控和定期监控，我们可以得到扩展名为nmon的监控文件，这些文件记录着系统资源的数据，需要配合分析工具（nmon analyser）进行解读。

　　1)   使用FTP工具从服务器上取下生成结果文件/nmon/log/sjfx212_120318_1723.nmon到本机。

　　2)   打开nmon_analyser.zip 包下的nmon analyser v33g.xls 文件，点击Analyse nomn data按钮，选择之前get下来的sjfx212_120318_1723.nmon文件。

 ）

2、  系统指标监控

系统指标监控一般通过性能测试工具（如LoadRunner、Jmeter等）以图形化方式监控，如下图所示，并发用户数与平均响应时间关系图。

如何分析监控的关键指标

 通过第二部分监控收集到性能度量关键指标，如何进行分析，并判断是否存在性能瓶颈呢？以下主要从资源指标与系统指标两方面进行阐述。

1、   资源指标分析

判断CPU是否是瓶颈的方法：一般情况下CPU满负荷工作，有时候并不能判定为CPU出现瓶颈，比如Linux总是试图要CPU尽可能的繁忙，使得任务的吞吐量最大化，即CPU尽可能最大化使用。因此，一般判断CPU为瓶颈，主要从两方面：一是CPU空闲持续为0，二是运行队列大于CPU核数（经验值3-4倍），即可判定存在瓶颈，对于CPU高消耗主要由什么引起的，可能是应用程序不合理造成，也可能是硬件资源不足，需要具体问题具体分析，比如问题SQL语句引起，则需要跟踪并优化引起CPU使用过高的SQL语句。

判断内存是否是瓶颈的方法：一般至少有10%可用内存，内存使用率可接受上限为85%。当空闲内存变小时，系统开始频繁地调动磁盘页面文件，空闲内存过小可能是内存不足或内存泄漏引起，需要根据系统实际情况监控分析。

判断磁盘I/O是否是瓶颈的方法：磁盘I/O对于数据库服务器、文件服务器、流媒体服务器系统来说，更容易成为瓶颈，一般从以下几个方面对磁盘I/O进行分析判断：

①计算每磁盘I/O数

每磁盘I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈，每磁盘I/O计算方法如下表：

RAID类型	计算方法
RAID0	(Reads+Writes)/Numbers of Disks
RAID1	(Reads+2*Writes)/2
RAID5	[Reads+(4*Writes)] /Numbers of Disks
RAID10	[Reads+(2*Writes)] /Numbers of Disks

②监控磁盘读写，如果磁盘长时间进行大数据量读写操作，且cpu等待超过20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读写性能。

判断网络带宽是否是瓶颈的方法：判断网络带宽是否是系统运行性能瓶颈的首要条件是网络带宽是否会影响系统交易执行性能。例如：减小网络带宽，并发用户数、响应时间与事务通过率等性能指标是否不能接受；或者增加网络带宽，并发用户数、响应时间与事务通过率等性能指标会得到明显提高。

在实际性能测试中，如果发现始终报连接超时，而实际手工访问可以正常访问，可以通过ping应用服务器IP或网关IP，如果出现网络严重延迟或丢包，则说明网络不稳定，需要检查网络。

通过对资源指标四个指标的分析，实际上各个方面都是互相依赖的，不能孤立的单从某个方面进行排查。当一个方面出现性能问题时，往往会引发其他方面的性能问题，例如，大量的磁盘读写势必消耗CPU和IO资源，而内存的不足会导致频繁地进行内存页写入磁盘、磁盘写到内存的操作，造成磁盘IO瓶颈，同时，大量的网络流量也会造成CPU过载，所以，在分析性能问题时，需要从各个方面进行考虑。

2、  系统指标分析

并发用户数：系统能够支持的用户数是系统容量的重要标志，并发用户数用于度量系统在高并发量访问下，系统的并行处理能力，一般如果系统中存在死锁、资源争用，在并发访问下，由于请求处于队列等待中，系统响应就会随着时间变慢。

一般情况下，选用高吞吐量、高数据库I/O、高商业风险的业务功能进行并发用户访问测试。

判断系统能够承受的最大并发用户数，通常以满足以下条件为准：

1、业务功能操作平均响应时间在合理范围之内

2、事务成功率在合理范围之内

3、 系统运行无故障（无异常宕机）

4、系统资源指标使用在合理范围内

平均响应时间：对于客户端用户来说，最直观的体验就是访问该页面快或者慢，即响应时间的长短。比如在持续并发性能测试过程中，客户感知访问应用很慢，监控到的平均响应时间也逐渐变长，这时就需要先借助于监控到的资源指标，首先排除资源方面的限制因素，再从应用本身进行定位，如可以采用页面细分工具（如httpwatch、Loadrunner Anaysis中的页面组件细分）分析响应比较慢的页面。

事务成功率、超时出错率：事务成功率越高，则表明系统处理能力越大；而失败事务主要由于系统响应慢，导致访问业务功能超时，或者系统业务功能异常，不能正常访问等，需要根据事务错误提示信息，具体分析。

综上所述，软件性能测试是执行、监控—〉分析—〉调优不断进行的过程，即监控是为分析提供更多的参考数据，分析是为了进行调优，调优是解决当前系统存在的性能瓶颈，为用户提供更好、更快的客户体验。

MySQL性能查看

mysql> show global status;
可以列出MySQL服务器运行各种状态值，另外，查询MySQL服务器配置信息语句：
mysql> show variables;
一、慢查询 
mysql> show variables like '%slow%'; 

+------------------+-------+ 
| Variable_name | Value | 
+------------------+-------+ 
| log_slow_queries | ON | 
| slow_launch_time | 2 | 
+------------------+-------+ 

mysql> show global status like '%slow%'; 

+---------------------+-------+ 
| Variable_name | Value | 
+---------------------+-------+ 
| Slow_launch_threads | 0 | 
| Slow_queries | 4148 | 
+---------------------+-------+

配置中打开了记录慢查询，执行时间超过2秒的即为慢查询，系统显示有4148个慢查询，你可以分析慢查询日志，找出有问题的SQL语句，慢查询时间不宜设置过长，否则意义不大，最好在5秒以内，打开慢查询日志可能会对系统性能有一点点影响，如果你的mysql是主-从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响又小。

tail -f mysql.slow