接口性能测试白皮书
一、性能测试术语解释
1)响应时间
响应时间即从应用系统发出请求开始,到客户端接收到最后一个字节数据为止所消耗的
时间。响应时间按软件的特点再可以细分,如对于一个 C/S 软件的响应时间可以细分为网络
传输时间、应用服务器处理时间、数据库服务器处理时间。另外客户端自身也存在着解析时
间、界面绘制呈现时间等。
响应时间主要站在客户端角度来看的一个性能指标,它是用户最关心、并且容易感知
到的一个性能指标。
2)吞吐率
吞吐率指单位时间内系统处理用户的请求数,从业务角度看,吞吐率可以用每秒请求数、
每秒事务数、每秒页面数、每秒查询数等单位来衡量。从网络角度看,吞吐率也可以用每秒
字节数来衡量。
吞吐率主要站在服务端的角度来看的一个性能指标,它可以衡量整个系统的处理能力。
对于集群或者云平台来说,吞吐率指标反映的是服务器集群对外整体能够承受的压力,该指
标比用户数更容易对比。
备注:吞吐量=吞吐率*单位时间
3)用户数
对于服务器集群或者云平台,几乎都是多用户系统,系统能提供给多少用户正常使用,
也是一个非常重要的度量指标。我们把这些用户按照使用系统的时机不同,做如下区分。
系统用户数(SystemUsers):指系统能够存储的用户量。
在线用户数(OnlineUsers):指用户通过身份确认后,处于能正常使用状态的用户个数。
并发用户数(Concurrentusers):指在某个时间范围内,同时正在使用系统的用户个数。
严格并发用户数(Strictlythenumberofconcurrentusers):指同一时刻都操作某个业务的
用户数。
1
在性能测试过程中,我们要去模拟实际用户来发请求。但是为了吐服务器产生更大的压
力,我们模拟的用户操作和实际的用户操作存在一定的差异(比如模拟的用户请求比实际用
户的请求更频繁),而且返种模拟的用户数和实际的用户数也难以相互换算。所以在度量服
务器集群能力时,吞吐率指标比用户数指标更实用。
二、性能测试方法及目标
1、性能测试方法
1) 基准测试(BenchmarkTesting)
基准测试是基于一定规模的数据量上进行单业务或按实际用户操作同比例组合业务的
测试,目的在于量化响应时间、吞吐率的指标,便于后续比对。
方法是做多组不同场景的测试,观察结果,抽取出几个关键数据做好记彔,用于以后进
行性能对比和评价。
2) 性能测试(PerformanceTesting)
通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产性能要
求。
特点:
(1)主要目的是验证系统是否具有系统宣称的能力。
(2)需要事先了解被测系统的典型场景,并具有确定的性能目标。
(3)要求在已确定的环境下运行。
3) 负载测试(LoadTesting)
通过在被测系统上不断增加压力,直到性能指标,例如“响应时间”超过预定指标或者某
种资源使用已经达到饱和状态。
特点:
(1)主要目的是找到系统处理能力的极限。
(2)需要在给定的测试环境下进行,通常也需要考虑被测系统的业务压力量和典型场
景,使得测试结果具有业务上的意义。
(3)一般用来了解系统的性能容量,或是配合性能调优使用。
4) 压力测试(StressTesting)
测试系统在一定饱和状态下,例如 CPU、内存等在饱和使用情况下,系统能够处理的会
话能力,以及系统是否会出现错误。
特点:
(1)主要目的是检查系统处于压力情况下是应用的表现。
(2)一般通过模拟负载等方法,使得系统的资源使用达到较高水平。
2
(3)一般用于测试系统的稳定性。
5) 配置测试(ConfigurationTesting)
通过对被测系统的软/硬件环境的调整,了解各种不同环境对系统性能影响的程度,从
而找到系统各项资源的最优分配原则。
特点:
(1)主要目的是了解各种不同因素对系统性能影响的程度,从而判断出最值得进行得
调优操作。
(2)一般在对系统性能状况有初步了解后进行。
(3)一般用于性能调优和规划能力。
6) 并发测试(ConcurrencyTesting)
通过模拟用户的并发访问,测试多用户并发访问同一个应用、同一个模块或者数据记录
时是否存在死锁或者其他性能问题。
特点:
(1)主要目的是发现系统中可能隐藏的并发访问时的问题。(并发处理能力)
(2)主要关注系统可能存在的并发问题,例如系统中的内存泄露、线程锁和资源争用
方面的问题。
(3)可在在开发的各个阶段使用,需要相关的测试工具的配合和支持。
7) 可靠性测试(ReliabilityTesting)
通过给系统加载一定的业务压力(例如资源在 70%~90%的使用率)的情况下,让应用
持续运行一段时间,测试系统在这种条件下是否能稳定运行。
特点:
(1)主要目的是验证系统是否支持长期稳定的运行。
(2)需要在压力下持续一段时间的运行。
(3)需要关注系统的运行状况。
8) 失效恢复测试(FailoverTesting)
针对有冗余备份和负载均衡的系统设计的,可以用来检验如果系统局部发生故障,用户
是否能够继续使用系统;以及如果这种情况发生,用户将受到多大程度的影响。
特点:
(1)主要目的是验证在局部故障情况下,系统能否继续使用。
(2)还需要指出,当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”
的方案。
(3)一般来说,只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测
试。
3
2、性能测试目标
概况来说,可分为 4 个方面:
1)能力验证
在系统测试或验收测试时,我们需要评估系统的能力,衡量系统的性能指标。系统的
能力可以是容纳的并发用户数,也可能是系统的吞吐率;系统的性能指标可以是响应时间,
也可以选择 CPU、内存、磁盘、网络的使用情况。
特点:
(1)要求在已确定的环境下进行。
(2)需要根据典型场景设计测试方案和用例。
一般采用的方法是:性能测试、压力测试、可靠性测试、失效恢复测试。
2)能力规划
评估某系统能否支持未来一段时间内的用户增长或是应该如何调整系统配置,使得系
统能够满足增长的用户数的需要。
特点:
(1)属于一种探索性的测试
(2)可被用来了解系统的性能以及获得扩展性能的方法,例如系统扩容规划。系统容
量可以是用户容量,也可能是数据容量,或者是系统的吞吐量(系统的处理能力)。对于集
群服务我们更多的是用吞吐率作为容量。
方法是①先对各子系统、组件进行性能测试,找出它们之间的最优配比;②然后再通过
各环节的水平扩展,计算出整体的扩容机器配比。
一般采用的方法是:负载测试、压力测试、配置测试。
3)性能调优
为了更好的发挥系统的潜能,定位系统的瓶颈,有针对性的进行系统优化。
方法是在进行系统调优时,我们需要做好基准测试,用以对比性能数据的变化,并反复
调整系统软硬件的设置,以使系统发挥最优性能。当然在进行系统优化时,我们会选取关键
的指标进行优化,返时可能要牺牲其他的性能指标。如目标是优化响应时间,我们可能选取
的策略是以空间换时间,以牺牲内存或扩大缓存为代价,还需要我们在各个性能指标中找到
平衡点。
一般对系统的调整包括以下 3 个方面:
(1)硬件环境的调整
(2)系统设置的调整
(3)应用级别的调整
一般采用的方法是:基准测试、负载测试、压力测试、配置测试和失效恢复测试。
4
4)发现缺陷
和其他测试一样,性能测试也可以发现缺陷。特别是严格并发访问时是否存在资源争夺
导致的响应时间过慢,或大量用户访问时是否导致程序崩溃。
方法是设置集合点,实现严格并发用户访问;或者设置超大规模用户突发访问等这样的
性能测试用例进行测试。
一般采用的方法是:并发测试。
三、性能需求分析
1) 性能需求获取
1.1 功能规格说明书
1.2 系统设计文档
1.3 运营计划
1.4 用户行为分析记录
2) 性能关键点选取
主要从以下 4 个维度进行选取:
(1)业务分析
确定被测接口是否属于关键业务接口或先分析出关键业务以间接获取该业务所访问的
接口。
(2)统计分析
若接口系统访问行为存在日志分析记录,则直接获取日访问量高的接口;否则根据接口
发布类型,选择第 3 方日志分析工具间接获取。
(1)IIS 日志分析工具:LogParser2.2+LogParserLizardGUI
下载地址:http://www.lizard-labs.com/log_parser_lizard.aspx
(2)Tomcat 日志分析工具:AWStatsv7.3
下载地址:http://www.awstats.org
(3)Nginx 日志分析工具:GoAccessv0.9
若 IIS 或 Tomcat 等接口应用服务器使用 Nginx 进行负载,则日志访问量要以负载为
准,因避免接口在 Nginx 设置缓存(即未进行透传)而导致统计不正确。
下载地址:http://www.goaccess.io
(3)技术分析
①逻辑实现复杂度高的接口(如判断分支过多或涉及 CPU/IO 密集型运算等)
②对系统(内存、CPU、磁盘 IO)及网络 IO 等硬件资源耗用高的接口
备注:若接口因逻辑修改而重构,则需重新分析。
(4)运营分析
5
由于运营推广活动导致日访问突增高的接口。
备注:若运营计划调整,则需重新分析。
3) 性能指标描述
3.1 响应时间
在一般情况下,弱交互类接口平均响应时间不超过 1 秒,强交互类接口平均响应时间不
超过 200 毫秒。
3.2 成功率
在一般情况下,接口响应成功率需达到 99.99%以上。
3.3 系统资源
若为最佳负载,则系统 CPU 及内存使用率建议区间[50%,80%],否则建议不超过 50%。
3.4 处理能力
立项申请书明确要求:在 XX 压力下(并发数)TPS 需达到 XX 或接口系统可支撑 XX 万
实时在线访问。
3.5 稳定性
在实际系统运行压力情况下,可稳定运行 N*24(一般 N>=7)小时。在高于实际系统运行
压力 1 倍的情况下,可稳定运行 12 小时。
3.6 特性指标
例:Java 类应用 FullGC 次数<=1 次/天
四、性能测试范围
1.业务范围
关键业务功能点描述。
2.设计范围
网络接入层、接口层、中间件、存储层等被测组件及拓扑结构描述。
五、并发数计算方法
做过一些性能测试的童鞋刚开始比较纠结某个或某一类接口的并发数如何计算,其实并
发数可以从用户业务和服务器的 2 个角度来看。
1) 80/X 原则
适用范围:无限制
以一项目为案例,母亲节当天接口服务器访问量分布如下所示,如何计算当天平均并发
6
数和高峰并发数?
通过百度统计平台 http://tongji.baidu.com/查看母亲节当天 UV 曲线分布与请求量呈线
性关系,如下所示:
采用微积分的思想,将每个时间点视为一个矩形,可以通过求和的方式求出整个分布图
的面积,如下所示:
其实每个矩形的长度均为 1(1 小时),故求面积时只需考虑宽度,即考虑每小时请求量
即可。
7
根据 80/X 原则,找出占据总体面积 80%的时间,选择尽可能大的点计算出占据总体面
积 80%的时间,发现点的个数是 7,意味着此时间长度占总时间长度 30%,则 80/X 原则转
换成 80/30 原则,如下所示:
故,平均并发数(每秒平均请求数)=80%*日请求量/1 天*30%
进而计算出最高峰值与平均并发数的倍数=2.25
故,高峰并发数(每秒高峰请求数)=2.25*平均并发数=
2.25*80%*日请求量/1 天*30%=6*日请求量/1 天
因 UV 与请求量曲线分布呈线性关系,日请求量=9.25*日 UV
故,高峰并发数=6*9.25*日 UV/1 天=55.5*日 UV/1 天
2) 公式法
适用范围:Web 类访问
公式(1)计算平均并发用户数:C=n*L/T
C 是平均的并发用户数;n 是 loginsession 的数量;L 是 loginsession 的平均长度;T 指考察的
时间段长度。
公式(2)计算并发用户数峰值:C’≈C+3 根号 C
C’指并发用户数的峰值,C 就是公式(1)中得到的平均的并发用户数。该公式的得出是假
设用户的 loginsession 产生符合泊松分布而估算得到的。
8