性能测试： 什么是性能测试？ 系统质量，系统承压能力的测试 为什么要做性能测试： 1. 评估系统的可扩展性 比如当前系统已经有5000个用户，那还能容纳多少个用户呢？ ---可以同过逐步加压的方式确定 2.保证系统在预期的负载下能正常运行 预期系统上线后的用户数是10万，那就得保证，系统在十万用户的并发下能正常使用而不会奔溃-或者直接宕机 3.有助于提升系统的运行速度 当系统有大量用户访问的时候，可能才能将一些影响系统的运行速度的因素放大，显示出来 ---需要去优化这些影响点 4.检查系统的健壮性 系统应该在服务器配置稍低的时候或者配置很好的时候都能正常运行，在用户量比较大的时候，或者用户量很少的时候都能正常运行 5.检查系统的可靠性 系统用户的访问量 有时候会低于预期或者高于预期 ---都需要系统能正常使用，而不至于直接崩溃，或者压力一大就直接开始报错 性能测试通过什么来测： 通过接口来测： 测的实际是后端和服务器---系统的逻辑大部分都体现在后端代码上 性能测试指标： 响应时间：接口的响应时间 并发数：系统能支持的最大用户数，或者测试时候设置的用户数 吞吐量：单位时间内成功发送的数据量 TPS（每秒事务数）: 单位时间内正确处理请求的数量 ---每秒能处理多少个请求 事务 ：成功发送一条数据，且正常将这个数据处理后返回结果 ---这个过程叫做一个事务 （就是一个接口请求过程） 资源使用率： 服务器的硬件资源： CPU：用户量对服务器CPU使用率的影响 内存：用量对内存的影响 磁盘：磁盘大小对接口性能的影响 网络：带宽 影响 系统响应速度 错误率： 接口处理的错误： 正常访问系统 压力相对比较小的时候 --不允许出现错误 大量用户访问系统的时候 --运行出现少量的错误 ---系统压力足够大的时候不足以处理所有请求 极大量的请求-用户访问 --会出现大量的错误 ---说明系统已经承受不住挂掉了 性能测试工具： jmeter： 开源，免费 扩展性强，可以自己去添加一些插件 上手比较简单 --功能比较强大 loadrunner： 收费，软件比较重量级 使用比较专业 --操作比较多一些 结果更精细准确一些 性能测试的流程： 1. 分析需求： 需要知道 在哪些场景下需要做性能测试： 1. 直接在需求文档中说明 ---需要做什么活动，预期的用户数是多少 2. 没有在需求文档中描述，活动的场景：拉新用户的，优惠限时抢购 需要知道并发用户数： 并发用户数的确定： 1. 需求文档中直接说明 2. 通过计算得到： 系统的总用户数---查看系统的数据统计 --10万 活跃用户数：就是经常使用软件的用户 --可能只有1万 统计出来 每个月的用户数 5000 统计出出来每天的最大用户数 ---那一天的用户数最大 --为什么这一天的用户数这么大 --1000 统计出用户主要集中在哪个时间段使用： 中午 11点 500 ---用户数的持续时间 以统计出来的这个时间 并发用户数增加20-30% 压测时间比实际时间也多出20-30% 然后再去压测 外卖平台：饭点 -中午或者晚上 代驾：晚上 需要确定性能指标： TPS（每秒事务数）： 需要达到多少才合格，和系统(软件)，服务器的硬件资源和访问的并发用户数都有关系 根据预期的用户量，然后根据大量用户对系统的持续访问时间--每个用户需要请求多少接口 2. 准备环境 需要确定在哪个环境下压测： 开发环境--测试环境--预发布(UAT)环境--生产环境 确定使用哪个工具去进行压测： jmeter压测 3.准备压测脚本 需要将要压测的场景的接口先用jmeter写好脚本--设置好并发数和压测时间 单接口压测： 抢购场景 多接口压测： 个人所得税--需要先选择需要申报的年度--需要选择税务类型--需要去增加一些免除项 4.执行脚本获取压测数据 通过执行脚本获取需要分析的性能数据： 直接通过jmeter获取 响应时间： 吞吐量： TPS： 错误率： 资源使用情况： 需要通过工具获取 统计服务器资源的工具 --nomn工具 5. 根据获取的压测数据分析结果 分析各项性能数据 是否符合我们的性能需求： 符合要求： 需要继续测试--需要了解系统的瓶颈在哪里 ---通过逐步加压的方式 需要了解系统的阈值： 系统的最高能承载的压力 需要测试系统是否具有抗风险能力 系统如果超过一些预期的值后有没有备用方案，使系统不至于直接挂掉 灾备机制（针对公司来说）： 将服务器放在同一个城市的不同区域 将服务器放在不同的城市 将服务器放在不同的省份 将服务器放在不同的国家 将服务器放在不同大州上 系统突然之间请求变大： 需要保证系统能有备用方案，不能直接挂掉 自动限流： 拒绝掉部分请求，直接接受处理能力之内的请求 自动扩容机制： 就是自己给自己扩充资源： 比如一个系统 本来分配的资源是 一个CPU，内存1个G，但是突然用户量起来了，系统当前的资源支撑不住，触发自动扩容机制 自己给自己扩容 --给自己增加一个或者多个CPU来处理，内存增加一个G，这个时候处理能力翻倍 #将请求转发到另外指定的服务器上协助处理 逐步加压的方式怎么做的： 怎么确定每次增加多少个并发数呢？ 比如：第一次 100个并发 ---系统很稳定，很流畅： 第二次 100+ 100/2 = 150 系统还是很稳定 第三次 150 + 150/2 = 225 系统响应有一定的卡顿了 第四次 225 + （225-150）/2 = 262.5 还是不是很卡 第五次 265.5 + （265-225)/2 = 285.5 一下很卡了，或者直接挂掉了 第六次 285.5 - （285.5-265.5）/2 刚好达到系统的最大瓶颈 。。。。。。 第N次。。 硬件性能指标： CPU的性能指标： 单核： 5,7,9 原则： cup使用率在50%以内的时候不需要处理 cup使用率在70%以上 需要关注一下 cpu使用率在90%以上的时候，告警，必须要处理 CPU怎么看： 多核： 指标可能会大于100% ---300% 4核：每个核 使用率是 60% 总的cpu使用率是 240% 不符合： 需要继续分析性能出现的问题 6. 根据结果 分析性能问题原因 --问题出来在哪里 需要找到问题出在哪里： 查看日志： 需要从系统的架构去详细看： 至上而下的流程： 客户端发起请求--->网关转发---->中间件（消息队列）--->应用服务器--->数据库服务器---->缓存服务器 网关： 防止服务器的IP地址直接暴露在外网上 中间件（消息队列）： 当请求数比较大的时候，需要对消息进行排序--排队 原则： 先进先出，后进后出 7.性能调优： 需要知道为什么出现了这个问题 ---需要对代码逻辑非常了解，甚至知道更优解 代码问题： 去建议开发改哪里的内容代码。或者跟他说怎么改 ---得说出来为什么要怎么改，为什么你的不行我的方案就可以 非代码问题： 装备不好 ---氪金---让老板买装备 ---硬件设备升级 实战： 1. 需求分析 做哪一个场景的压测： 单接口： 登录 压测 --并发数为10 压测1分钟 多接口： 2. 准备环境 直接在教学服务器上压测 压测工具 选择jmeter 3. 准备压测脚本 jmeter线程组界面解释： 线程组属性： 线程数：并发数 Ramp-Up时间：线程组启动时间，设置时间为n ---意思是 线程组需要在n秒内全部启动 循环次数： 线程组需要执行多少次 永远：如果勾选则线程组会一直执行下去 延迟创建线程直到需要：在使用线程的时候就创建，使用完就销毁 ---会导致执行多并发的任务时，线程组会频繁的创建销毁，对测试性能有一定影响 一般不勾选 调度器配置： 需要勾选调度器后才能使用 持续时间： 一般需要配合线程组属性的循环次数来使用 ---一般循环次数勾选永远，然后这里的持续时间就是当执行到对应的时间后直接结束线程 延迟启动时间： 等待时间 --线程组等待N秒后才开始启动 jmeter 插件安装： 1. 下载插件 jmeter-plugins-manager-1.7.jar #下载地址 https://jmeter-plugins.org/install/Install/ 2. 将下载的插件 jar包 放在 你jmeter安装目录的--lib目录下的--ext文件夹下 3. 重启jmeter 4.选项--底部plugins-manager--选择Available Plugins --勾选jpgc -standard set --右下角勾选apply changes and restart jmeter 安装 逐步加压方式压测： 逐步加压线程组： 使用 ip@gc-ultimate Thread Group 线程组实现逐步加压： 解释： Start Threads Count：当前行需要启动的线程总数 Initial Delay/sec：延时启动当前行的线程，单位:秒 S tartup Time/sec：启动当前行所有线程达峰值所需时间，单位:秒 Hold Load For/sec：当前行线程达到峰值后的稳定加载时间，单位:秒 Shutdown Time：停止当前行所有线程所需时间，单位:秒 需要服务器承受瞬间的并发： 集合点： --通过同步定时器实现 4. 执行脚本获取压测数据 5. 分析数据： 查看 服务器的资源使用情况： nomn工具 在服务器上下载 安装nomn工具 nmon工具使用： 文档：https://www.jianshu.com/p/4559edae548a 安装： 1.下载 ： wget https://sourceforge.net/projects/nmon/files/nmon16d_x86.tar.gz/download 2.安装 mkdir /usr/local/src/nmon/ #创建安装目录 mv nmon16d_x86.tar.gz /usr/local/src/nmon/ #移动下载的压缩包到创建的目录下 cd /usr/local/src/nmon/ #切换到安装目录 tar -xzvf nmon16d_x86.tar.gz #解压 3.查看当前linux系统版本 cat /etc/*release 4.找到和系统版本对应的 nmon文件 赋权并重命名 chmod +x nmon_x86_64_linux mv nmon_x86_64_linux /usr/local/bin/nmon #设置系统变量 使用： 直接在命令行中输入nmon，会直接跳出 nmon 的交互式窗口，直接输入c会显示当前节点cpu使用率 参数含义： f 参数:生成文件,文件名=主机名+当前时间.nmon T 参数:显示资源占有率较高的进程 s 参数:-s 10表示每隔10秒采集一次数据 c 参数:-s 10表示总共采集十次数据 m 参数:指定文件保存目录 举例：nmon -f -s 5 -c 24 -m ./ #每隔5秒采集一次，一共采集24次，就是2分钟的数据（生成的文件已标红） 结果分析： 1. 将服务器上生成的资源监控结果从服务器导到本地 2.下载 nmon analyser 工具 3.解压后打开 nmon analyser.xlsm 文件，点击“Analyze nmon data” 生成图表报告文件 如果出现禁用宏，点击安全选项，启用内容 采集数据： 需要先执行 nmon工具开始采集数据，然后再执行脚本 分布式压测： 控制机： 执行脚本的电脑 --脚本的配置以及并发数都在这上面设置 负载机（肉机）： 承受压力 #控制机也可以当成负载机 控制机给负载机分发任务：并发压测1万的并发 负载机有5台每台的负载就是2000 负载机的负载一定是均衡 负载机和控制机一定要在同一个网络下（同一个wifi）： 1. 负载机和控制机连接同一个wifi 2.设置负载机： 1.将预计的负载机的防火墙关闭 2.打开jmeter安装目录的下（bin目录下） jmeter.properties文件 3.在文件中查找关键字：remote_hosts 4.将负载机的ip地址写在后面 --如果说把自己（控制机）也作为负载机测试 ---IP地址：127.0.0.1 5.保存后重启jmeter 3. 负载机上以管理员的方式打开 jmeter_server.bat 文件 4. 控制机执行 ---运行--选择远程启动--可以选择启动全部，也可以选择某一台负载机使用