大家都想做性能测试，因为现在面试门槛高，如果你没接触过，那么无形的减分不少。但是性能测试不是每个人都能接触的。如何做性能测试呢？
最近有新手做性能测试，不停地来问我问题，感觉他连很基本的概念都不清楚，就开始轰轰烈烈的干起来了，出了问题，就指望我手把手来解决。
“磨刀不误砍柴工”，我们搞清楚了性能测试的技巧，测试起来就会顺畅很多。
首先需要了解几个概念。
响应时间
Response Time: RT
响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒或毫秒。
不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：
· 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
· 金融企业：1秒以下为佳，部分复杂业务3秒以下。
· 保险企业：3秒以下为佳。
· 制造业：5秒以下为佳。
系统处理能力
统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。
一般情况下，用以下几个指标来度量：
· HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。
· TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。
· QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS，一般情况下用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求。
无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：
· 金融行业：1000TPS~50000TPS，不包括互联网化的活动
· 保险行业：100TPS~100000TPS，不包括互联网化的活动
· 制造行业：10TPS~5000TPS
· 互联网电子商务：10000TPS~1000000TPS
· 互联网中型网站：1000TPS~50000TPS
· 互联网小型网站: 500TPS~10000TPS
并发用户数
Virtual User: VU
并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力
一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。
系统的性能由TPS决定，跟并发用户数没有多大关系。
系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。
一般情况下，大型系统（业务量大、机器多）做压力测试，10000～50000个用户并发，中小型系统做压力测试，5000个用户并发比较常见。
错误率
Failure Ratio: FR
错误率指系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100%。稳定性较好的系统，其错误率应该由超时引起，即为超时率。
不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%
网络吞吐量
Network Throughput
网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。
网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。
如何获取 VU 和 TPS
并发用户数(VU)获取方式：
· 已有系统：可选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数，并发用户数可以取10%，例如在半个小时内，使用系统的用户数为10万，那么取10%（即1万）作为并发用户数基本就够了。
· 新系统：没有历史数据作参考，建议通过业务部门进行评估。
TPS获取方式：
· 已有系统：可选取高峰时刻，在一定时间内（如3-10分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以2-5倍作为峰值的TPS，例如峰值3分钟内处理订单18万笔，平均TPS是1000，峰值TPS可以是2000-5000。
· 新系统：没有历史数据作参考，建议通过业务部门进行评估。
性能测试比较难做，主要是不好模拟真实环境，我们不敢用生产线上的系统来压测。
但是测试系统很难接近生产环境，所以我们尽可能的让测试环境接近真实环境。
还有一点是可接受的性能的标准不太好定。有的人觉得响应时间是3秒能接受，有的人却觉得太慢。如果是某宝上秒杀，1秒钟都觉得好漫长。
测试环境
测试环境的风险主要体现在跟生产的差异度，测试结果的参考价值会打一定程度的折扣，可以视自身情况选择合理的方式，比如看重入口网络的检验的，可以测试环境和生产环境共享入口。对测试环境系统平台、中间件、数据库等不熟悉和了解，也会导致瓶颈不易分析、不易调优等。
测试环境调研，需要调研如下内容：
· 系统架构：系统如何组成的，每一层功能是做什么的，与生产环境有多大差异，主要为后面进行瓶颈分析服务和生产环境性能评估，这个很重要。
· 操作系统平台：操作系统是哪种平台，进行工具监控。
· 中间件：哪种中间件，进行工具监控和瓶颈定位。
· 数据库：哪种数据库，进行工具监控和瓶颈定位。
· 应用：启动多少个实例，启动参数是多少，进行问题查找和瓶颈定位。
可以配合APM工具（如ARMS）进行中间件、数据库、应用层面的问题定位。
测试指标
测试指标一般分为业务指标、资源指标、应用指标、前端指标：业务指标：如：并发用户数、TPS（系统每秒处理事务数）、成功率、响应时间。资源指标：如：CPU资源利用率、内存利用率、I/O、内核参数(信号量、打开文件数)等。应用指标：如：空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时等。前端指标：如：页面加载时间，网络时间（DNS，连接时间、传输时间等）。
业务指标
业务响应时间(Response Time):这个指标所有相关人员都明白其含义，业务部门更需要此指标的具体值，一般情况下，不同系统的业务响应时间期望值是不同的，１秒以内最佳；像淘宝系统业务ＲＴ基本在几十毫秒以内。
业务处理能力（Transaction Per Second）:具体指标为 TPS（Transaction Per Second，即系统每秒处理事务数），这个指标是衡量系统的处理能力的一个非常重要的指标。TPS 可以参照同行业系统和结合具体业务，中小企业TPS值为501000笔/秒，银行TPS值为100050000笔/秒，淘宝TPS值为30000~300000笔/秒。
成功率:这个指标是衡量系统处于压力下，业务的成功率，一般业界成功率要大于99.6%。
资源指标
一般情况下，系统资源指标也不能超过瓶颈值，例如CPU资源利用率<=75%,内存无SWAP, 磁盘和网络I/O不能自身处理能力。理想的情况下，当系统压力上不去的时候，资源成为瓶颈（正常情况下，非其他瓶颈情况下导致），这样的话加资源，系统处理能力还会上升的，但是遗憾的是，很多系统性能测试资源都没达到瓶颈的时候，压力就上不去了。
测试策略
1、 基准测试
在系统没有压力的情况下对各功能进行单线程的测试,测试结果主要用来作为基准值为后续测试结果做比对参数。
2、 单交易测试
采用梯度测试方法对单个功能或接口在不同压力下的进行测试,可以得出单个功能的最大TPS,结合基准测试的结果可以分析性能的增长趋势(响应时间/系统资源等增长趋势)。
3、 混合场景测试
使用相关模型进行测试的场景,主要验证整体性能是否满足上线要求,或者给出基于模型的最大TPS。
4、 稳定性测试
一般在系统最大TPS的 80% 压力下 执行 12或24小时,主要验证系统在执行大量业务交易(一般模拟一个月的业务量)后性能表现。
瓶颈分析
瓶颈定位的目的是对系统中存在的瓶颈点进行分析，为调优做准备，系统的性能瓶颈点主要分布在操作系统系统资源、中间件参数配置、数据库问题以及应用算法上，对于有针对性的进行调优，有利于系统性能的提升。
分析系统的瓶颈点遵循的规则如下：
· 操作系统资源消耗：CPU、Memory、Disk I/O、Network I/O。
· 中间件指标：线程池(Thread Pool)、数据库连接池(JDBC)、JVM(GC/FULL GC/堆大小)。
· 数据库指标：效率低下SQL、锁等待/死锁、缓存命中率、会话、进程等。
· 应用：方法耗时、算法、同步和异步、缓存、缓冲。
· 压力机：压力机资源消耗，一般情况下，压力机成为瓶颈的可能性非常低。
调优
调优的目的是提升系统的性能，针对系统的“瓶颈点”对症“下药”,通过测试验证系统的性能有多大的提升。
系统调优遵循的规则如下：
· 中间件调优：线程池、数据库连接池、JVM。
· 数据库调优：效率低下SQL、死锁和锁等待、缓存命中率，进程和会话参数。
· 应用调优：方法耗时、算法、同步和异步、缓存、缓冲。
· 系统资源：一般情况下，系统资源(CPU\大部分是由应用和参数设置不合理导致的，并非系统资源真的不够”用”。
实战
· 业务场景
日常任务管理网站从本地 IDC 机房迁移上云时，需要提前评估系统的性能瓶颈。
· 业务指标
1) 满足对集团内的1000用户的并发访问。
2) 300用户数并发对日程进行创建、修改、删除等操作。
3) 100用户数并发登录。
4) 在并发较高的情况下，用户不需要等待过长时间。
· 业务流程
用户登录：登录用户的信息来自文件输入。
创建日程：日程信息为随机生成。
日程修改：由上一个创建事件输出的 ID 进行修改。
查看日程：随机获取月、周、日的日程信息。
压测过程及结论
第一次压测，按照10%的施压配置进行测试，每次递增10%（每次持续1分钟），到40%时开始发现，和日程相关的 API 请求成功率开始下降，经DMS、CloudMonitor等工具排查后，诊断为数据库死锁导致。
经过分析，死锁原因是项目中事务调用产生的 PAG 范围锁引起，经过优化后恢复正常。
第二次压测，直接全局调速40%， 当压力测试进行到80%时，云监控上见到的ECS、RDS内存消耗超过90%，RT明显增高到4000+ms，并初现超时的情况。
通过增加4个 ECS 节点，并对 RDS 进行升配，从而解决问题。
第三次压测，直接全局调速70%， 整体系统运行正常，施压到100%时getSchedule偶发会出现 RT 过大或者直接错误的问题。经过一系列排查，该 API 调用参数范围过大时会导致处理时间过长或者直接提示超时。
调整 Tomcat 连接超时时长，并对该 API 输入参数范围进行限制，解决了该问题。
第四次压测，施压配置从10%升高到100%，压测过程中，在100%压测5分钟的情况下，系统 RT 稳定，无失败的情况出现，系统利用率较好。
其实性能测试，用生活中的例子来考虑，就会豁然开朗。
比如你去银行柜台办事。
如果前面是一个老太太，就在那墨迹，（响应时间）肯定快不了。
如果客户经理跑过来，跟你在自助机子上弄，（系统处理能力）TPS肯定快很多。
如果前面有很多人排队办同样的业务。（并发用户）
如果柜台同时开放很多个窗口办同样的业务，那么叫号也快很多。（吞吐量）
如果窗口渐渐挂起一些暂停业务的牌子，所有业务都在某个窗口慢吞吞的办理。（瓶颈）
银行如何提高他的办事效率呢？
可以有客户经理(中间人)，辅助办事。（中间件调优）
可以多加一些ATM机。(应用调优)
可以有一些值班经理，盖章签字随叫随到。(系统资源调优)
可以用光纤。（网络调优）
提高银行内部系统速度。（数据库调优）
好了，啰嗦了这么多，对你有帮助吗？
