一、性能测试流程
1、首先制定性能测试计划，确定各项指标的目标（期望）
2、申请压力机
3、制定性能测试方案
4、执行脚本（如用jmeter命令执行jmx文件）、监控数据（zabbix、CAT）
5、分析数据，并出性能测试报告
二、性能测试关键指标估算法
（1）性能测试成果物要点：
| 成果物 |
要点 |
默认选项 |
性能测试方案
|
确认预期业务指标及监控方案 |
并发数（根据预期指标计算取得） 响应时间（默认：B/S 3，5，8原则；API小等于200ms，特殊复杂逻辑接口时间可适当延长） 处理能力（tps，qps根据预期指标计算取得） 事务成功率（大等于99.99%） CPU（使用率小等于75%） 内存（使用率小等于85%） 磁盘I/O （Disk Time小等于85%，Disk%busy小等于60%） 吞吐量 （小等于30%） |
| 确认被测环境与生产环境处理能力性能比 |
根据性能比计算取得 根据性能比，将预期业务指标换算成单台预期业务指标 |
| 确认被测环境、网络拓扑结构 |
测试环境 |
| 确认测试类型 |
基准（确认基线）、负载（确认系统所能承受的最大压力，评估最大处理能力）、混合场景及稳定性（确认系统长时间稳定运行。设计并发数按负载最大并发数的80%，业务等比进行） |
| 确认测试计划、测试用例、场景 |
|
| 性能测试报告 |
确认被测版本 |
|
| 确认实际被测环境与生产环境处理能力性能比 |
确认是否与方案一致 |
| 确认基准、负载测试、稳定性测试结果、预期业务指标是否达成 |
负载测试超限条件：响应超时、事务成功率未达标、负载超标 稳定性测试失败条件：事务成功率未达标 |
| 确认遗留风险及改进方案 |
|
（2）性能测试关键指标估算方法
| 估算方法 |
前提条件 |
计算公式 |
例 |
| 2.8法 |
B/S系统提供UV，PV、接口提供被调次数，考察时间长度 |
并发数=uv*0.8/(8小时*0.2*3600秒)*3倍 处理能力（tps）=pv*0.8/(8小时*0.2*3600秒) 处理能力（tps）=被调次数*0.8/(8小时*0.2*3600秒) |
8小时中，80%的访问量集中在20%的时间里 |
| 简单峰值法 |
B/S系统提供UV，PV、接口提供被调次数，考察时间长度 |
并发数=uv*0.9/（（12-8）*3600秒）*3倍 处理能力（tps）=pv*0.9/（（12-8）*3600秒） 处理能力（tps）=被调次数*0.9/（（12-8）*3600秒） |
8～12点处理90%的访问量，其他时间处理10%的访问量 |
| 并发数精算法 |
平均每天访问用户数、一天内用户从登录到退出的平均时间、考察时间长度 |
平均并发数=平均每天访问用户数*一天内用户从登录到退出的平均时间/考察时间长度 并发数=平均并发数+3√平均并发数 平均并发数=400*4/8=200 并发数=200+3√200=242 |
每天400个用户访问系统，平均时长4小时，访问时间段8小时内 |
| 并发数估算法一 |
系统最大在线用户数 |
并发数 = 系统最大在线用户数*12% 并发数 = 2000*12%=240 |
系统最大在线用户数2000 |
| 并发数估算法二 |
处理能力（tps），平均响应时间 |
并发数＝处理能力（tps）*平均响应时间 并发数＝200*0.5=100 |
tps:200trs/s 平均响应时间：500ms |
性能比等比估算法
|
测试环境，生产环境机型相同，数量不同，如应用为耗CPU类 |
则认为生产环境、测试环境处理能力比例为 6：1 |
生产环境、测试环境机型相同，内存，磁盘大小不同，数量比例6：1 |
| 测试环境，生产环境机器CPU频率相同或差别不大，内核数不同，机器数量不同，如应用为耗CPU类 |
则认为生产环境、测试环境处理能力比例 大于8：1 |
测试环境，生产环境机器CPU频率相同或差别不大，内核数比例为2：8，内存，磁盘大小不同，机器数量比例1：2 |
| 测试环境，生产环境机型相同，数量相同，内存大小不同，如应用为耗内存类 |
则认为生产环境、测试环境处理能力比例为 6：1 |
生产环境、测试环境机型相同，内存数量比例6：1 |
| 测试环境，生产环境机器CPU频率相同或差别不大，内核数不同，机器数量不同，内存大小不同，如应用为耗内存类 |
因为是耗内存类，则忽略cpu差异，认为生产环境、测试环境处理能力比例为12：1 |
测试环境，生产环境机器CPU频率相同或差别不大，内核数比例为2：4，内存数量比例是1：6，机器数量比例1：2 |
三、聚合报告中的90%Line讲解
比如，假设某个考生在入学考试中的语文部分的原始分数为54分。相对于参加同一考试的其他学生来说，他的成绩如何并不容易知道。但是如果原始分数54分恰好对应的是第70百分位数，我们就能知道大约70％的学生的考分比他低，而约30％的学生考分比他高。
在jmeter中的聚合报告中有90%LIne，95%Line，99%Line
90%line 很多人认为是90%的用户的响应时间，其实这种说法是不准确的，那是怎么去理解90%line的正真的含义呢？
其他不多说直接上
例1
11,23,24,35,35,38,40,42,45,66 这里有10组数据那么90%line是多少呢？
90Line%应该是45.
ps：90%Line表示的是90%的百分位，意思是说90%的请求时间不超过45ms。
例2
2、2.1、2.5、3、3.4、3.4、4、4、4、4、5、5、5、5.9、5.91、6.8、8、12、24、24.1
90%line(90%百分位)在第18位上，值是12ms：意思是说90%的请求时间不超过12ms
一组数由小到大进行排列，找到他的第90%个数（假如是12），那么这个数组中有90%的数将小于等于12 。
PS：95%Line，99%Line同理可推出是什么意思了。
四、TPS上不去的几种可能性原因？
1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2、连接池
可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
3、垃圾回收机制
从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS
也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
4、数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，
就会导致数据库事务处理过慢，影响到TPS。
5、通信连接机制
串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。
6、硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
7、压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
8、压测脚本
还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。
提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。
9、业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
10、系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
五、TPS与RT和服务器之间的联系
| TPS |
RT |
资源利用率 |
说明 |
| 小 |
小 |
低 |
性能没有发挥出来：
- 负载不够，压力机问题
- 脚本问题，并发用户数问题
- 负载受限制（中间件配置）
- 文件句柄，连接数的限制
|
| 小 |
大 |
低 |
1， 脚本是否有问题（事务包含了太多页面，场景是否合理） 2， 资源是否做了限制（JVM配置） 3， 性能问题，走正常排查流程（CPU等待，线程死锁等） 4， 负载机压力过大，压力发出去 |
| 小 |
大 |
高 |
1.性能问题，走正常排查流程 |
| 大 |
小 |
高 |
- 性能佳的表现
- 脚本中失败率过高，脚本空跑
|
| 大 |
大 |
低 |
- 不存在
|
| 大 |
大 |
高 |
- 达到性能瓶颈
|
| 大 |
小 |
高 |
1．资源利用率不超过警界值，测试结论：测试通过 |
| 小 |
小 |
高 |
- 被压服务器配置可能不够
- 代码写的有问题，运算复杂导致特别消耗CPU
|
ps：产生异议的可以私下沟通
六、查看高消耗CPU的代码
1、先使用top看下CPU占用高的进程，找出进程的进程ID（pid）
查看方法：top
2、根据进程ID（pid）查看是进程的那些线程占用CPU高。
查看方法：top -Hp pid
3. ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpu
//打印用户、进程id、父进程id、线程id（对于此次很重要）、运行时间、CPU使用率、启动命令并按CPU使用率排序
4.通过jstack 32381 >/home/baseuser/stack.log
打印出log日志，通过查询十六进制“7ea8”
==============================================================================================================
附录1：性能测试调研/申请注意事项
1.系统介绍
明确这个系统或者接口的功能....
2.性能调研
2-1 收集被压测的功能模块，请求地址，参数，请求类型（http/dubbo），对参数是否需要进行参数化操作等信息；
2-2 收集被压测服务器的测试环境，是生产环境还是测试环境，如果是测试环境，生产与测试环境硬件配比情况是什么，还有数据库量级收集，如果是生产环境，要计划压测计划时间（避免影响生产业务）
2-3系统业务量或者各个压测接口的业务量，例如：
XXX访问接口流量
| 1月份 |
2月份 |
3月份 |
4月份 |
5月份 |
6月份 |
7月份 |
8月份 |
9月份 |
10月份 |
11月份 |
12月份 |
| 1989080 |
434234 |
5646456 |
534534 |
654645 |
6756768 |
7845645 |
536453 |
5623354 |
3453454 |
34546546 |
676576 |
根据月高峰流量收集天高峰流量
11月份每天高峰流量
| 1日 |
2日 |
3日 |
4日 |
5日 |
6日 |
7日 |
8日 |
9日 |
10日 |
11日 |
.....30日 |
| 1151551 |
1951951 |
1177551 |
1451461 |
1651531 |
1451351 |
1551550 |
1653531 |
1556558 |
1371581 |
1751131 |
....... |
.....同理类推，收集高峰流量日下的每小时高峰流量
XXX访问接口响应时间收集
收集 小时/分钟高峰流量段下的接口或者系统响应时间
2-4
根据设计预期，每个接口或者每个功能模块期望读写效率和响应时间是多少，支持多少的并发量
2-5 系统架构收集
a.目的了解数据量的走向
b.后期为定位调优排除提供方向
2-5 提前申请好压力机器资源
3.测试申请
3-1 计划测试压测时间(包括风险评估，环境可测性评估，人员安排评估，修复调优时间评估等）
3-2 明确填写压测接口（接口请求类型，http还是dubbo ）
3-3 明确压测目的，有预估期望性能指标
比如1.预期TPS多少，RT多少的情况下，最大支持多少并发数；压测出系统报错为止；压测出系统的性能瓶颈；压测出在多少TPS下响应时间是多少；压测出在多RT下最大TPS是多少等
2.希望做稳定性压测，持续8小时情况下看一下接口或者功能模块是否稳定等
3-4 明确测试环境与生产环境差异（可以配比换算），需要填写测试环境硬件地址和生产地址
附录2：性能指标估算杂谈（一）
一、 性能测试需求分析
1.1 性能测试需求内容
a) 测试场景及用例，用例访问URL；
b) 目标接口方法的入参、出参；
c) 外部依赖的服务细节；
d) 关键数据: 数据量、高峰业务PV量
e) 预期性能指标：响应时间、QPS、TPS等
1.2 性能指标估算
1.2.1 高峰业务PV量
1) 二八法：若80%的访问量集中在20%的时间里，可用此分析方法
具体计算公式为： tps = (24小时的PV值*80%)/（24*3600*20%）
举例有，假如中文站每日的访问量为500万，其中19:00-23：40，访问量为400万，其余时间段的访问量很平坦，而且其余时间段的总访问量为100万，那么就可以用二八法，其计算公式为 tps = (500万*0.8)/(24*3600*0.2)。
2）简单峰值法
若在每天的某一时段里有很大的访问量，其他时间相对较少，可以用简单峰值法，其实二八法只是简单峰值法的一个特例。
具体计算公式为：tps =(24小时的PV值)/（峰值时间段中的小时数*3600）
举例有，假如中文站每日的访问量为500万，其中17:00-24:00这个时间段里面访问量为450万，其他时间段的访问量很平缓，那么，我可以用简单峰值法近似计算，其计算公式为 tps = 500万/（（24-17）*3600）
3）无峰值法
若24小时里的访问量都是平稳波动的，没有峰值，那么可以采用无峰值计算方法
具体计算公式为： tps= (24小时的PV值)/（24*3600）
举例有，假如中文站每日的访问量为500万，每小时的访问量都为20万左右，那么，可以用无峰值法来近似计算，其计算公式为 tps = 500万/(24*3600)。
二.性能测试指标
需求收集之后，我们已经从性能需求文档中提取出了业务性能测试指标，主要包括PV到TPS的转换以及响应时间要求，接下来我们需要进行进一步的需求分析过程。
1.了解系统架构、明确压力流向
理解架构图中各个节点的功能与交互关系，然后结合需求文档，根据具体业务场景，确定各分支压力流向，针对每一个测试场景，都要根据系统架构图进行上述分析，明确了各场景的压力流向，即明确了性能测试过程中的监控对象。监控对象确定后，需要进一步分析明确测试重点。明确测试重点，将有助于我们进行测试环境相关的测试策略的选择。
2 明确测试环境
2.1服务器数量确定
2.2 服务器配置确定
机器性能需求（32位/64位 4C/8C）,是否是同一个网段
性能测试关注的主要硬件配置及OS参数
- 主机/ip
- 硬件配置（机型 CPU 内存 网络）
- 操作系统及参数调整（如：内核参数是否优化）
附录3：性能指标估算杂谈（二）
并发用户数：指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数（系统用户数）。
TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标
在术语中解释了TPS是每秒事务数，但是事务时要靠虚拟用户做出来的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。
性能测试分类：
1.负载测试：在一定软件，硬件以及网络环境下，运行一种或多种业务，在不同虚拟用户数的情况下，测试服务器的性能指标是否在用户的要求范围内，以此来确定系统所能承受的最大用户数，最大有效用户数以及不同用户下的系统响应时间以及服务器的资源利用率
2.压力测试：在一定软件，硬件以及网络环境下，运行一种或多种业务，模拟大量的虚拟用户对服务器产生负载，使服务器资源处于极限状态下并长时间持续运行，以测试服务器在高负载情况下是否能稳定工作，与负载测试获取的峰值性能数据不同，压力测试强调的是在极端情况下系统的稳定性，这个时候处理能力已经不重要了。
3.容量测试：在一定软件，硬件以及网络环境下，在数据库中构造不同级别的数据记录，运行一种或者多种业务在一定虚拟用户数量的情况下，获取不同数量级别的服务器指标，来确定数据库的最佳容量和最大容量。
4.配置测试：是在不同的软件，硬件，网络环境配置下，运行一种或者多种业务，在一定的虚拟用户数量情况下，获得不同配置的性能指标，用于最佳的设备以及参数配置，通过不同的配置，来得到系统性能变化情况。
5.基准测试：在一定软件，硬件以及网络环境下，模拟一定数量的虚拟用户运行一种或多种业务，，将测试结果作为基线数据，在系统调优或者系统评测过程中，通过运行相同的业务场景比较测试结果，确定调优的结果是否达到预期效果或为系统的选择提供决策数据。基准测试一般基于配置测试，通过配置测试得到数据，并将这个数据作为基准来比较每次调优后的性能是否有所改善。
6.并发测试：通过模拟多个用户并发访问同一个应用，接口，或者业务功能模块
如何获取Vu和TPS
并发用户数(Vu)获取
新系统：没有历史数据作参考，只能通过业务部门进行评估。
旧系统：对于已经上线的系统，可以选取高峰时刻，在一定时间内使用系统的人数，这些人数认为属于在线用户数，并发用户数取10%就可以了，例如在半个小时内，使用系统的用户数为10000，那么取10%作为并发用户数基本就够了。
TPS获取
新系统：没有历史数据作参考，只能通过业务部门进行评估。
旧系统：对于已经上线的系统，可以选取高峰时刻，在5分钟或10分钟内，获取系统每笔交易的业务量和总业务量，按照单位时间内完成的笔数计算出TPS，即业务笔数/单位时间（5*60或10*60）
如何评价系统的性能
针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，如果必须要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。
对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。
性能测试策略
做性能测试需要一套 标准化流程及测试策略，并发用户数只是指标考虑的一个，在做负载测试的时候，一般都是按照梯度施压的方式去加用户数，而不是在没有预估的情况下，一次加几 万个用户，，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义
总结
系统的性能由TPS决定，跟并发用户数没有多大关系。在同样的TPS下，可以由不同的用户数去压
系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。
