性能测试基本理解

性能测试基本了解

什么是性能测试

通过模拟生产环境运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。

性能测试应用的四个领域

1. 能力验证：关注在给定的软硬件条件下，系统能否具有预期的能力表现，例如，在要求平均响应时间小于2秒的前提下，如何判断系统是否能够支持50万用户/天的访问量？
2. 规划能力：关注如何使系统具有我们要求的性能能力，例如，某某系统计划在一年内获客量在到xxx万，系统到时候是否能支持这么多用户量？如果不能需要如何调整系统的配置？
3. 性能调优：主要用于对系统性能进行调优，例如，某某系统上线运行一段时间后响应速度越来越慢，此时应该如何办？
4. 缺陷发现：发现缺陷或问题重现、定位手段，例如，某些缺陷只有在高负载的情况下才能暴露出来，如线程锁、资源竞争或内存泄露。

性能测试类型

我们在做性能测试的时候一般都是笼统的称为性能测试，其实性能测试分为多个类型：负载测试，压力测试，性能测试，基准测试，并发测试，配置测试，稳定性测试，失效恢复测试。下面就详细说说这些名词之间的区别和特点。

负载测试

负载测试是对被测系统不断增加压力（即用户并发数），直至性能指标超过预期或者某项资源使用达到饱和状态（就是加压到系统崩溃）。重点观察系统正常运行的最大值时候的一些数据和资源使用。观察程序、网络、服务器、还是数据库等哪个方面存在瓶颈。

目的：发现系统处理能力的极限。找出问题所在，做这个就是为了发现系统是否还有隐藏的能力。用来改进调优。

压力测试

压力测试是系统在一定饱和状态下，例如cpu、内存、磁盘I/O在饱和使用情况下，系统能够处理能力，以及系统是否会出现错误。（可以参考负载测试情况）

目的：该方法通过增加压力，使系统资源使用保持在较高的压力下，检验此时应用的表现，重点在于有误出错信息产生，系统对应用的响应时间等。

性能测试

性能测试一般是根据模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。也可以说是在特定的运行条件下验证系统的能力状态。比如做100个并发，持续10分钟等。查看平均响应时间和TPS是否满足生产的指标或者是设计的指标。评估正常使用的功能。不是破坏性的。

目的：验证系统是否达到了设计要求和是否可以满足需求。需要将环境确认不变更。做之前需要了解业务流程，最重要是做之前先确定好目标即指标要求。

基准测试

基准测试常用于敏捷开发中，通过每次迭代性能变化判断是否达到预期目标。

目的：直观反映每次迭代的性能变化，可作为验收测试的一部分。

并发测试

并发测试是模拟多用户并发访问同一个应用、模块或者数据记录时可能发生的性能问题（如内存泄漏、线程锁和资源争用方面的问题）。

配置测试

配置测试是通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。（tomcat配置、apache配置、Nginx配置、连接池配置、JVM配置等）

目的：了解各种不同因素对系统系能影响的程度，从而判断出最值得进行的调优操作。

稳定性测试

稳定性测试是在给系统施加一定压力，持续运行一段时间（7*24），观察系统能否稳定运行。（也可以说是长时间的压力测试）

失效恢复测试

稳定性测试是如果系统发生故障，系统能否继续使用。

目的：测试系统的容错能力以及故障恢复能力（一般使用负载均衡、限流降级等技术）。

 

测试工具选择

1. 压测工具使用频率最高的就是jmeter、PerformanceRunner、LR，这三个工具的原理基本一致，都是基于协议，使用多线程去模拟并发用户，设计场景。
2. 资源监控工具：nmon、

常用的性能指标

性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试；不同人群关注的性能指标各有侧重。从应用层看一般只关心吞吐量、响应时间等外部指标。后台服务的所有者不仅仅关注外部指标，还会关注CPU、内存、服务器负载、网络、磁盘IO等内部指标。

 

应用层：

类型	指标	解释
应用层	TPS（transaction per second）	TPS表示服务器每秒处理的事务数，他是衡量系统处理能力的一个非常重要的指标，在性能测试中，通过检测不同用户的TPS,可以估算出系统处理能力的拐点。
	RPS（Request Per Second）	每秒请求数
	QPS(Queries Per Second)	是每秒查询率，是一台服务器每秒能够相应的查询次数，即1秒内完成的请求数量，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
	HPS（Hit Per Second）	点击率，每秒点击数，一般在性能测试中，用来描述HTTP Request,它代表每秒发送的HTTP请求数量，和RPS概念完全一样
	RT(Response-time)	响应时间是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。响应时间是指执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间
	ERROR	一批请求中结果出错的请求所占比例

 

 

 

 

 

服务层：

类型	指标		解释
服务层	Load Average		在一段时间内的平均负载，系统工具top、uptime等提供1分钟、5分钟和15分钟的平均负载值。
	CPU	us	用户态使用的cpu时间百分比
		sy	系统态使用的cpu时间百分比
		ni	用做nice加权的进程分配的用户态cpu时间百分比
		id	空闲的cpu时间百分比
		wa	cpu等待IO完成时间百分比
		hi	硬中断消耗时间百分比
		si	软中断消耗时间百分比
	内存	VIRT	进程所使用的虚拟内存的总数。它包括所有的代码，数据和共享库，加上已换出的页面，所有已申请的总内存空间
		RES	进程正在使用的没有交换的物理内存（栈、堆），申请内存后该内存段已被重新赋值
		SHR	进程使用共享内存的总数。该数值只是反映可能与其它进程共享的内存，不代表这段内存当前正被其他进程使用
		SWAP	进程使用的虚拟内存中被换出的大小，交换的是已经申请，但没有使用的空间，包括（栈、堆、共享内存）
		DATA	进程除可执行代码以外的物理内存总量，即进程栈、堆申请的总空间
	磁盘IO	tps	该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。
		kB_read/s	每秒从设备（driveexpressed）读取的数据量，单位为Kilobytes
		kB_wrtn/s	每秒向设备（driveexpressed）写入的数据量，单位为Kilobytes
		kB_read/s	读取的总数据量，单位为Kilobytes
		kB_wrtn/s	写入的总数量数据量，单位为Kilobytes
		iops	每秒处理读/写请求的数量
	网络	r(t)xpck/s	发包接包率
		r(t)xKB/s	发送接包大小
		r(t)xdrop/s	接收发送丢包率

性能测试准入标准

不同的指标行业参考标准

应用层：

类型	指标	行业参考标准
应用层	TPS（transaction per second）	无论TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下： 金融行业：1000TPS~50000TPS，不包括互联网化的活动 保险行业：100TPS~100000TPS，不包括互联网化的活动 制造行业：10TPS~5000TPS 互联网电子商务：10000TPS~1000000TPS 互联网中型网站：1000TPS~50000TPS 互联网小型网站: 500TPS~10000TPS
	RPS（Request Per Second）
	QPS(Queries Per Second)
	HPS（Hit Per Second）
	RT(Response-time)
	ERROR

 

服务层：

类型	指标		行业参考标准
服务层	Load Average		压力测试时系统负载应接近但不能超过阈值，并发测试时的系统负载最高不能超过阈值的80%，稳定性测试时，系统负载应在阈值的50%左右
	CPU	us	CPU 利用率要低于业界警戒值范围之内，即小于或者等于75%; CPU sys%小于或者等于30%; CPU wait%小于或者等于5%；
		sy
		ni
		id
		wa
		hi
		si
	内存	VIRT	现在的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内存是否有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。
		RES
		SHR
		SWAP
		DATA
	磁盘IO	tps	磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于70%。
		kB_read/s
		kB_wrtn/s
		kB_read/s
		kB_wrtn/s
		iops
	网络	r(t)xpck/s	网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。
		r(t)xKB/s
		r(t)xdrop/s

 

瓶颈征兆

1. 内存瓶颈征兆

buff/cache增长过快

Physical Memory（物理内存）使用率过高

GC过快，内存溢出

1. IO瓶颈

IO队列过长

IO处理时间过长

IO吞吐量过低

await与svctm差值过大

1. cpu瓶颈

负载过高

（sys+usr）利用率超过80%或者低于50%

Iowait过高

运行队列过长

上下文切换过快，中断过快

1. 网络瓶颈

丢包，延迟过高

mtu值过小