一、性能测试指标
1、吞吐量：单位时间内，能处理多少请求；（单位：秒、每秒处理的请求量）
（1）TPS事务请求
用户操作伴随数据变化，例如：淘宝下单，40万订单/秒
（2）QTP查询请求
用户查询数据，例如：打开淘宝查看某个商品页面
2、响应时间（Response Time）
用户体验视角：网站打开快不快？
一个请求从用户发起，到收到服务器响应，所需要的时间：1、页面打开响应时间；2、具体单个资源响应时间；
3、并发处理能力
海量用户使用系统时候，在系统不崩溃情况下，能够支撑多少人同时使用
单位：秒
（1）同时在线：
例子：10w人在线观看视频；session会话信息保存到 服务器存储 里面
（2）同时操作：
例子：支付宝同时操作付款
4、资源占用率
（1）成本角度：最小成本【最少资源】支持最多的吞吐量、支持最小的响应时间，包括：内存、网络、磁盘等资源
例子：两个app，功能一样，做的事情一样；
1、第一个app：能够运行在5年前的手机上，2GB运行内存；
2、第二个app：能够运行在3年前的手机上，4GB运行内存；
结论：第一个app性能好
（2）同时处理100个请求：需要占用多少CPU、内存、网络、磁盘
例子：打开一个网站的请求，加载一系列图片 、html、js、css等内容
需要观察：
1、内容压缩；
2、服务器将数据传输到浏览器客户端，观察服务器网络带宽资源：（1）每秒能够传输多少KB的数据；（2）需不需要加大服务器带宽；
3、当前这个系统部署在服务器，占用网络带宽是否太多？是否导致每一秒只能返回一个请求所需要的数据？
二、性能测试场景
1、追求更大的并发【担心用户太多，搞垮系统用户量太多，担心处理不过来】
2、追求更短的响应时间【觉得系统响应太慢】
3、追求更少的资源【成本太高，需要服务器太多】
例子：用户量激增的情况下，系统是否崩溃
1、前置条件：
（1）性能测试环境 通过采取和正式环境相同的机型；
（2）固定硬件配置：CPU、内存、网络、磁盘；
（3）固定软件配置：链接池配置、JVM配置、限流配置；
（4）不允许性能测试过程中动态变化，否则性能测试失去准确性；
2、机器数量：
（1）首先单机压测
目标： 测试系统是否能承载5000/s并发请求
生产服务器会有5台：1、理论上每台服务器能够承载1000/s请求即可；2、那么结论：如果一台服务器能够承载1000/s请求；
（2）再小集群压测
1、一台机器 性能吞吐量---》1000/s；
2、4台机器 理论吞吐量---》4000/s；
3、集群部署 机器之间的网络通信损耗；
4、例如： 4台机器--->实际吞吐量3600/s 8台机器--->7200/s；
5、损耗值需要压测才能出来，经验值大概是95%；
3、测试方式：
（1）模拟海量用户，请求系统；
1、线程就是模拟用户；
2、线程数量不是随便写的：
3、也不一定是测试决定的；
4、市场方面：需要市场规模预估，例如：当前2亿用户；
5、产品方面：（1）需要产品经理产品规划，例如：产品日活20%；（2）用户操作习惯，例如：早上8-9点用的人最多，集中一个小时-30%-360w，每分钟6w人，每秒1000人；
6、架构师方面：（1）线上数据分析，后台服务器统计系统数据；（2）经验值预估：每秒1000*10，一般经验是数量的10倍；
（2）预估线上用户并发数量最高峰值；
（3）尖峰测试+阶梯压测
1、某一瞬间或者多个频次下用户数和压力陡然增加的场景；
2、Ultimate Thread GroupJmeter插件里面“终极”线程组：
1、“终极”意味着不需要更多的线程组插件 ；
2、关键字段意思
（1）Start Threads Count：开始线程数；
（2）Initial Delay,sec：初始延迟，秒
（3）Startup Time,sec：启动时间，秒
（4）Hold Load Forsec：保持加载，秒
（5）Shutdown Time：关机时间
3、执行命令：/u01/test/apache-jmeter-5.4.1/bin/jmeter -n -t spike.jmx -I test1.jtl -e -o ./report
4、性能测试是否通过标准
1、请求错误率
2、响应时间在接受范围
3、资源使用在使用范围：服务器监控
标签：请求,性能,用户,响应,测试,服务器,Jmeter From： https://www.cnblogs.com/zhaocbbb/p/17602508.html