吞吐率主要站在服务端的角度来看的一个性能指标，它可以衡量整个系统的处理能力。对于集群或者云平台来说，吞吐率指标反映的是服务器集群对外整体能够承受的压力，该指标比用户数更容易对比。
3.用户数
对于服务器集群或者云平台，几乎都是多用户系统，系统能提供给多少用户正常使用，也是一个非常重要的度量指标。我们把这些用户按照使用系统的时机不同，做如下区分。
系统用户数（SystemUsers）：指系统能够存储的用户量。
在线用户数（OnlineUsers）：指用户通过身份确认后，处于能正常使用状态的用户个数。
严格并发用户数（Strictlythenumberofconcurrentusers）：指同一时刻都操作某个业务的用户数。
在性能测试过程中，我们要去模拟实际用户来发请求。但是为了吐服务器产生更大的压力，我们模拟的用户操作和实际的用户操作存在一定的差异（比如模拟的用户请求比实际用户的请求更频繁），而且返种模拟的用户数和实际的用户数也难以相互换算。所以在度量服务器集群能力时，吞吐率指标比用户数指标更实用。
02
性能测试方法及目标
1.性能测试方法
1.1基准测试（BenchmarkTesting）
方法是做多组不同场景的测试，观察结果，抽取出几个关键数据做好记彔，用于以后进行性能对比和评价。
1.2性能测试（PerformanceTesting）
通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。
特点：
（1）主要目的是验证系统是否具有系统宣称的能力。
（2）需要事先了解被测系统的典型场景，并具有确定的性能目标。
（3）要求在已确定的环境下运行。
1.3负载测试（LoadTesting）
（1）主要目的是找到系统处理能力的极限。
（2）需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景，使得测试结果具有业务上的意义。
（3）一般用来了解系统的性能容量，或是配合性能调优使用。
1.4压力测试（StressTesting）
测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。
（1）主要目的是检查系统处于压力情况下是应用的表现。
（2）一般通过模拟负载等方法，使得系统的资源使用达到较高水平。
（3）一般用于测试系统的稳定性。
1.5配置测试（ConfigurationTesting）
通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。
（1）主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行得调优操作。
（2）一般在对系统性能状况有初步了解后进行。
（3）一般用于性能调优和规划能力。
1.6并发测试（ConcurrencyTesting）
通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
（1）主要目的是发现系统中可能隐藏的并发访问时的问题。
1.7可靠性测试（ReliabilityTesting）
（1）主要目的是验证系统是否支持长期稳定的运行。
1.8失效恢复测试（FailoverTesting）
针对有冗余备份和负载均衡的系统设计的，可以用来检验如果系统局部发生故障，用户是否能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。
（1）主要目的是验证在局部故障情况下，系统能否继续使用。
（2）还需要指出，当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案。
（3）一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。
2.性能测试目标
概况来说，可分为4个方面：
2.1能力验证
（1）要求在已确定的环境下进行。
（2）需要根据典型场景设计测试方案和用例。
一般采用的方法是：性能测试、压力测试、可靠性测试、失效恢复测试。
2.2能力规划
（1）属于一种探索性的测试
（2）可被用来了解系统的性能以及获得扩展性能的方法，例如系统扩容规划。系统容量可以是用户容量，也可能是数据容量，或者是系统的吞吐量（系统的处理能力）。对于集群服务我们更多的是用吞吐率作为容量。
方法是①先对各子系统、组件进行性能测试，找出它们之间的最优配比；②然后再通过各环节的水平扩展，计算出整体的扩容机器配比。
一般采用的方法是：负载测试、压力测试、配置测试。
2.3性能调优
为了更好的发挥系统的潜能，定位系统的瓶颈，有针对性的进行系统优化。
一般对系统的调整包括以下3个方面：
（1）硬件环境的调整
（2）系统设置的调整
（3）应用级别的调整
一般采用的方法是：基准测试、负载测试、压力测试、配置测试和失效恢复测试。
2.4发现缺陷
方法是设置集合点，实现严格并发用户访问；或者设置超大规模用户突发访问等这样的性能测试用例进行测试。
一般采用的方法是：并发测试。
03
性能需求分析
1.性能需求获取
1.1功能规格说明书
1.2系统设计文档
1.3运营计划
1.4用户行为分析记录
2.性能关键点选取
主要从以下4个维度进行选取：
2.1业务分析
确定被测接口是否属于关键业务接口或先分析出关键业务以间接获取该业务所访问的接口。
2.2统计分析
若接口系统访问行为存在日志分析记录，则直接获取日访问量高的接口；否则根据接口发布类型，选择第3方日志分析工具间接获取。
（1）IIS日志分析工具：LogParser2.2+LogParserLizardGUI
（2）Tomcat日志分析工具：AWStatsv7.3
（3）Nginx日志分析工具：GoAccessv0.9
若IIS或Tomcat等接口应用服务器使用Nginx进行负载，则日志访问量要以负载为准，因避免接口在Nginx设置缓存（即未进行透传）而导致统计不正确。
2.3技术分析
（1）逻辑实现复杂度高的接口（如判断分支过多或涉及CPU/IO密集型运算等）
（2）对系统（内存、CPU、磁盘IO）及网络IO等硬件资源耗用高的接口
备注：若接口因逻辑修改而重构，则需重新分析。
2.4运营分析
由于运营推广活动导致日访问突增高的接口。
备注：若运营计划调整，则需重新分析。
3.性能指标描述
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次/天
04
性能测试范围
1.业务范围
关键业务功能点描述。
2.设计范围
网络接入层、接口层、中间件、存储层等被测组件及拓扑结构描述。
五、并发数计算方法
做过一些性能测试的童鞋刚开始比较纠结某个或某一类接口的并发数如何计算，其实并发数可以从用户业务和服务器的2个角度来看。
1.80/X原则
适用范围：无限制
以一项目为案例，母亲节当天接口服务器访问量分布如下所示，如何计算当天平均并发数和高峰并发数？
查看母亲节当天UV曲线分布与请求量呈线性关系，如下所示：
其实每个矩形的长度均为1（1小时），故求面积时只需考虑宽度，即考虑
每小时请求量即可。
故，平均并发数（每秒平均请求数）=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
公式（2）计算并发用户数峰值：C’≈C+3根号C
C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的loginsession产生符合泊松分布而估算得到的。
例1：
C=400*4/8=200
C’≈200+3*根号200=242
为了更好地理解上述公式，将其转换为如下公式：
例2：
分析：
吞吐率=8000*2（整个业务操作需加载2次页面才能完成）
通过以上方法得到业务并发数后，我们可以进一步分析业务访问了哪些接口，我们只要模拟这些接口调用方式和调用时序就行了。
有时我们需要计算某一个或某一类接口的并发数，我们可以按如下步骤进行分析计算：
（1）梳理出被测接口被访问的业务场景和每个业务场景访问的次数
（2）通过上述方法计算出业务场景的并发用户数
接口并发数=场景1并发用户数*业务场景接口调用次数1+场景2并发用户数*接口调用次数2+…
05
性能测试用例与场景
脚本模板
场景模板
06
性能测试工具选择
1.数据建模工具
DataFactory是一种强大的数据产生器，它允许开发人员和QA很容易产生百万行有意义的正确的测试数据库，该工具支持DB2、Oracle、Sybase、SQLServer数据库，支持ODBC连接方式，无法直接使用MySQL数据库，可间接支持。
2.脚本开发工具
（1）若考虑脚本运行效率，则可考虑底层开发语言C或支持异步通信的语言JS，我们可以分别选择：Loadrunner或Node.js的IDE环境进行开发。
（2）若考虑脚本开发效率，则可考虑代码复用性，可以选择面向对象语言C#或Java，为此我们可以分别选择：VS2008及以上版本+对应LR.NET控件或者Eclipse4.0及以上版本+JDK1.7及以上版本。
HTTP、Socket等协议接口性能测试脚本开发过程，请详见附件：
HTTP接口性能测试之脚本开发与性能问题分析.pdf
利用LR.Net控件完成性能测试脚本编写方法.pdf
Node.js学习入门手册.pdf
3.压力模拟工具
（1）若为Java类接口且单机并发数控制在500内，则可选择Jmeter或者Loadrunner。
（2）若为WebService类接口且单机并发数控制在500内，则可选择SoapUI或者Loadrunner。
（3）若单机并发数超过500且控制在5000内，则可选择Loadrunner。
（4）若单机并发数超过5000，则建议采用负载集群，即采用“中控（ControlCenter）+多机部署（LoadGenerator）”方案。
4.性能监控工具
4.1监控工具
无论Windows或Linux平台，一般存在的是一个或一组进程实例，我们可以选择Loadrunner或Nmon来监控。有时为了获取被测应用的一些特性指标，可以选择被测组件自带的性能工具集或监控系统。常见应用服务器监控工具推荐如下：
4.2监控平台
监控机器主要对被测集群服务器的服务或资源使用情况进行监控，比如各种开源的监控工具，MRTG：流量监控；CACTI：流量预警，性能报告Smokeping:IDC质量监控；综合监控：Nagios、Zenoss、Ganglia、Zabbix、Sitescope、HypericHQ等，如下所示：
4.3第三方监控云服务（APM）
APM提供端到端应用性能管理软件及应用性能监控软件解决方案，包含移动，浏览器，应用，基础设施，网络，数据库性能管理等，支持Java、.NET、PHP、Ruby、Python、Node.js、iOS、Android、HTML5等应用性能监控管理，主流云服务包括听云、OneAPM等，如下所示：
07
性能测试结果分析
1.指标分析
a.容量：系统能够承载的最大用户访问量是多少系统最大的业务处理量是多少
b.稳定性:系统是否支持7*24小时(一周)的业务访问。
举例来说，通常接口系统均会直接或间接地访问数据库层介质（如Mysql、Oracle、SQLServer等），此时我们需考虑由接口系统产生压力下存储介质的性能情况，通常我们会选择分析指标如下：
（1）连接数（Connections）
（2）每秒查询数/每秒事务数（QPS/TPS）
（3）每秒磁盘IO数（IOPS）
（4）缓存命中率（BufferHits）
（5）每秒发生的死锁数（DeadLocks/sec）
（6）每秒读/写字节数（Read/WriteBytes/sec）
对于Windows或Linux平台具体指标监控及分析方法，请详见附件：
《Windows操作系统性能监控工具和指标分析V1.0》.pdf
《Linux操作系统性能监控分析手册V1.0》.docx
2.建模分析
2.1理发店模型
根据这种性能表现，图中划分了三个区域，分别是LightLoad（较轻的压力）、HeavyLoad（较重的压力）和BuckleZone（用户无法忍受并放弃请求）。在LightLoad和HeavyLoad两个区域交界处的并发用户数，我们称为“最佳并发用户数（TheOptimumNumberofConcurrentUsers）”，而HeavyLoad和BuckleZone两个区域交界处的并发用户数则称为“最大并发用户数（TheMaximumNumberofConcurrentUsers）”。
2.2压力变化模型
图中：
a点：性能期望值
b点：高于期望，系统资源处于临界点
c点：高于期望，拐点
d点：超过负载，系统崩溃
2.3容量计算模型
以一网站性能测试为案例：
1.通过分析运营数据，可以知道当前系统每小时处理的PV数
2.通过负载测试，可以知道系统每小时最大处理的PV数
即整理得
系统每小时PV处理剩余量=系统每小时最大处理的PV数—系统每小时处理的PV数
假设该网站用户负载基本呈线性增长，现有系统用户数为70万，根据运营推广计划，1年内该网站发展用户将达到1000万，即增长了14倍。即整理得：
系统每小时PV处理增加量=当前系统每小时处理的PV数*14—当前系统每小时处理的PV数
每天系统负载增加率=100%/365=2.74%（备注：此处将未来系统用户数达到1000万的负载定义为100%）
系统每天PV处理增加量=系统每小时PV处理增加量*每天系统负载增加率*24
所以，我们可以知道在正常负载条件下：
系统可支持正常运行天数=系统每小时PV处理剩余量*24/系统每天PV处理增加量
假设该网站后续部署升级天数已知，这样我们可以知道提前升级的天数：