负载压力测试

负载压力测试是在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力。

负载压力测试有助于确认被测系统是否能够支持性能需求，以及预期的负载增长等。负载压力测试不只是关注不同负载场景下的响应时间等指标，它也要通过测试来发现在不同负载场景下会出现的，例如速度变慢、内存泄漏等问题的原因。负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性能测试、疲劳强度测试、大数据量测试等内容。一般包括如下： 

1、性能测试

性能测试用来保证产品发布后系统的性能能够满足用户需求。其中系统性能包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。

2、性能评测

性能评测包括：在真实环境下，检查系统服务等级的满足情况，评估并报告整个系统的性能；对系统的未来容量作出预测和规划。

负载压力测试结构剖析

3、性能调优

性能调优一般的步骤为首先查找形成系统瓶颈或者故障的根本原因，其次是进行性能调整和优化，最后便是评估性能调整的结果。

4、负载测试

负载测试时通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。

5、压力测试

压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。

6、并发性测试

并发性测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点。并发性测试分为三类：

a、应用在客户端性能的测试；

b、应用在网络上性能的测试；

c、应用在服务器上性能的测试；

7、疲劳强度测试

8、大数据量测试 

大数据量测试包括独立的数据量测试和综合数据量测试两类。

负载压力测试的目的：

1.在真实环境下检测系统性能，评估系统性能以及服务等级的满足情况

例如电信计费软件，众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个看起来简单的两个步骤，当成百上千的终端同时执行这样的操作时情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者需要模拟系统负载压力，预见软件的并发承受力，这是在测试阶段就应该解决的重要问题。

一个企业自己组织力量或委托软件公司代为开发的应用系统，在生产环境中实际使用起来以后，往往会产生这样一个问题，即这套系统能不能承受大量的并发用户同时访问，这个问题是系统负载压力需求的体现。

这里强调在真实环境下检测系统性能，在实施过程中大家认为这样做会遇到很多阻力，比如系统上线运行之后，真实环境下不允许负载压力测试为系统带来大量的垃圾数据，测试数据与真实业务数据混在一起无法控制测试结果，负载压力测试如果使服务器宕机会给系统带来巨大损失等。那么在这种条件下不允许的情况下，应该采用什么肃然措施弥补呢？我们可以使用一种“模拟环境”来做测试，这种环境是指与实际真实应用环境基本等级保持一致的测试环境。

2.预见系统负载压力承受力，在应用实际部署之前，评估系统性能。

目前的大多数公司企业需要支持成百上千名用户，各类应用环境，以及由不同供应商的元件组装起来的复杂产品。难以预知的用户负载和越来载复杂的应用程序，使公司时时担忧会发生投放性能差，用户遭受反应慢，系统失灵等问题。其结果就是导致公司收益的损失。

检测系统性能强调对系统当前性能的评估中，通过评估，可以在应用实际部署之前，预见系统负载压力承受力。这种测试的意义在于指导系统总体设计，既可以避免浪费不必要的人力、物力和财力，又避免硬件和软件的设计不匹配，使系统具有更长、更健壮的生命力。

如何确定系统的“负载压力承受力”是一个非常复杂且关键的问题。

对于系统性能检测，有时我们所从事的工作仅仅是被动监控一些性能指标，而预见系统负载压力承受力，则不可避免地会借助自动化的负载压力测试工具。

3.分析系统瓶颈、优化系统

系统性能检测和预见为分析系统瓶颈和优化提供了原始数据，打好了基础。

系统瓶颈即应用系统中导致系统性能大幅下降的原因。

瓶颈大大降低了系统性能，一般情况下，发现瓶颈并找出原因并不是件容易的事。很多时候你可能无法准确定位系统瓶颈之所在。瓶颈可能定位在硬件中，也可能定位在软件中，对于后者，是无能为力的。硬件中的瓶颈可能会非常容易排除,一般来讲，解决硬件瓶颈的方法只是简单地向系统中添加CPU、磁盘或者内存等，如果硬件瓶颈是由于系统缓冲区设计或内存总线造成的，那么通常情况下就无能为力了。硬件瓶颈与软件瓶颈相比，更建议先解决软件瓶颈，原因有三，其一是软件瓶颈往往导致系统性能衰减更快，反过来讲，消除软件瓶颈，系统性能提升更快；其二是人为因素更易导致软件瓶颈，要消除软件瓶颈，开发人员会更主动，并且可以节省资源；其三，盲目增加硬件则无形中增加维护费用，将来，软硬件不匹配的问题终究还会暴露出来。

优化调整系统是在发现瓶颈，故障定位之后要完成的事情，实现优化之后即可消除瓶颈，提高性能。

性能测试指标：

通用指标（指Web应用服务器、数据库服务器必需测试项)

指标	说明
ProcessorTime	服务器CPU占用率，一般平均达到70%时，服务就接近饱和
Memory Available Mbyte	可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重
Physicsdisk Time	物理磁盘读写时间情况

Web服务器指标

指标	说明
Requests Per Second（Avg Rps）	平均每秒钟响应次数＝总请求时间 / 秒数
Avg time to last byte per terstion （mstes）	平均每秒业务脚本的迭代次数 ,有人会把上面那个混淆
Successful Rounds	成功的请求
Failed Requests	失败的请求
Successful Hits	成功的点击次数
Failed Hits	失败的点击次数
Hits Per Second	每秒点击次数
Successful Hits Per Second	每秒成功的点击次数
Failed Hits Per Second	每秒失败的点击次数
Attempted Connections	尝试链接数

数据库服务器性能指标

指标	说明
User 0 Connections	用户连接数，也就是数据库的连接数量
Number of deadlocks	数据库死锁
Butter Cache hit	数据库Cache的命中情况

系统的瓶颈定义

性能项	命令	指标
CPU限制	vmstat	当%user+%sys超过80%时
磁盘I/O限制	Vmstat	当%iowait超过40%(AIX4.3.3或更高版本)时
应用磁盘限制	Iostat	当%tm_act超过70%时
虚存空间少	Lsps，-a	当分页空间的活动率超过70%时
换页限制	Iostat, stat	虚存逻辑卷%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍时
系统失效	Vmstat, sar	页交换增大、CPU等待并运行队列

稳定系统的资源状态

性能项	资源	评价
CPU占用率	70%	好
	85%	坏
	90%+	很差
磁盘I/0	<30%	好
	<40%	坏
	<50%+	很差
网络	<30%带宽	好
运行队列	<2*CPU数量	好
内存	没有页交换	好
	每个CPU每秒10个页交换	坏
	更多的页交换	很差