项目压测优化实践思路（中）

2024/5/13 16:04:01

线程组配置详解01-线程数：用来发送http请求的线程的数量...

线程组配置详解01-线程数：用来发送http请求的线程的数量线程组常用来模拟一组用户访问系统资源（API接口）。假如客户机没有足够的能力来模拟较重的负载，可以使用JMeter的分布式测试功能，通过一个JMeter的Master来远程控制多个JMeter的Salve完成测试。02-循环次数：循环执行多少次操作循环次数表示了循环执行多少次操作！循环次数直接决定整个测试单个线程的执行时间，和整体测试执行时间。单线程执行时间?= 单请求平均响应时间 * 循环次数整个测试耗时?= 单线程执行时间 + (Ramp-Up - Ramp-Up / 线程数)03-Ramp-Up：建立全部线程耗时Ramp-Up Period (in-seconds) 需要花费多久的时间启动全部的线程，默认值是0代表同时并发。用于告知JMeter 要在多长时间内建立全部的线程。JMeter常用插件已有内容的分析维度不够：需要加入新的插件TPS、QPSRT【平均响应时间】压力机活动线程数服务器资源信息...开启插件下载：在线下载方法如下图所示：常见的插件如下：1、PerfMon：(Performance + Monitor)监控服务器硬件，如CPU，内存，硬盘读写速度等 Allows collecting target server resource metrics2、Basic Graphs：主要显示平均响应时间，活动线程数，成功/失败交易数等 Average Response Time 平均响应时间 Active Threads 活动线程数 Successful/Failed Transactions 成功/失败事务数3、Additional Graphs：主要显示吞吐量，连接时间，每秒的点击数等 Response Codes Bytes Throughput Connect Times Latency????Hits/s01-配置插件如果可以配置如下三个监听器，就表示插件已经安装成功！执行压力测试，就可以看见压测的每秒事务数、响应时间，活动线程数等压测结果响应时间：jp@gc - Response Times Over Time活动线程数：jp@gc - Active Threads Over Time每秒事务数：jp@gc - Transactions per Second响应时间：jp@gc - Response Times活动线程数：jp@gc - Active Threads每秒事务数：jp@gc - Transactions per Second02-性能关键指标分析1）RT：响应时间平均值：请求响应的平均时间是6092ms中位数：50%请求响应时间都在6392ms之内P90：90%的请求都在7290ms之内响应结束P95：95%的请求都在7762ms之内响应结束P99：99%的请求都在8891ms之内响应结束最小值：请求响应最小时间3ms*大值：请求响应的*大时间是13656ms2）压力机活动线程数压力机活动线程数表明压测过程中施加的压力的情况3）TPS：每秒的事务数数字愈大，代表性能越好；4）QPS：每秒的查询数量数字愈大，代表性能越好；（1tps >= QPS）5）吞吐量：每秒的请求数量数字愈大，代表性能越好；服务器硬件资源监控【精简版】压测的时候，我们需要实时了解服务器【CPU、内存、网络、服务器Load】的状态如何，哪如何监控服务器的资源占用情况呢？方法有很多种：使用操作系统命令：top、vmstat、iostat、iotop、dstat、sar...使用FinalShell使用JMeter压测工具PerfMon使用Grafana+Prometheus+node_exporter监控原理：01-配置服务端代理注意：服务器硬件资源的监控，必须在服务端安装serverAgent代理服务，JMeter才能实现监控服务端的cpu、内存、io的使用情况。ServerAgent下载地址## 默认启动运行 startAgent.sh 脚本即可## 服务启动默认4444端口，根本连接不上，因此自己创建一个部署脚本文件对此进行部署，且把端口修改为7879nohup java -jar ./CMDRunner.jar --tool PerfMonAgent --udp-port 7879 --tcpport 7879 > log.log 2>&1 &## 赋予可执行权限chmod?755?startAgent.sh启用7879端口后，服务器的cpu，io，内存使用情况就顺利的监控到了。02-监控CPU：Elapse time：消耗时间Performance Metrics：性能指标idle：CPU空闲iowait：IO等待system：系统占用CPU user：CPU用户占用03-监控网络：接收字节：byteSrecv【单位：比特、KB、MB】发送字节：byteSent【单位：比特、KB、MB】发送(transport)：tx接收(receive)：rx04-监控内存：usedPerc：每分钟使用内存【单位：字节、KB、MB】freePerc：每分钟未使用内存【单位：字节、KB、MB】好处：可以将所有信息汇总到JMeter工具中来，查看非常方便。弊端：数据记录时间有限，记录数据的量也有限05-监控系统整体负载情况：服务器上执行以下命令：#查询服务器资源使用情况toptop?-H如下图所示，可以看到系统负载 load average 情况，1分钟平均负载，5分钟平均负载，15分钟平均负载分别是 0.08, 0.03, 0.05 ；统计信息区前五行是系统整体的统计信息：好处：不依赖环境，操作系统自带的命令，随时可以查看。弊端：无法记录历史数据，不能看到变化的趋势怎么理解系统资源的指标呢，怎么理解系统负载呢？06-性能关键指标分析1）服务器：CPU、内存、网络IOCPU内存网络IO2）系统负载：load average1.什么是Load Average？系统负载System Load是系统CPU繁忙程度的度量，即有多少进程在等待被CPU调度（进程等待队列的长度）。平均负载（Load Average）是一段时间内系统的平均负载，这个一段时间一般取1分钟、5分钟、15分钟。多核CPU和单核CPU的系统负载数据指标的理解还不一样。在类Unix系统中，系统负载是衡量计算机系统执行的计算工作量的指标。举个栗子：while(true) 这样程序不耗时，cpu会飙高，但是load average不会走高。说明程序在计算，但是并没有执行耗时工作，所以Load Average并不高。我们在核查服务器负载因需要重点关注loadaverage。2.Load的数值是什么含义？不同的CPU性质不同：单核，双核，四核 -->>单核CPU三种Load情况举例说明：把CPU比喻成一条（单核）马路，进程任务比喻成马路上跑着的汽车，Load则表示马路的繁忙程度。情况1-Load小于1：不堵车，汽车在马路上跑得游刃有余：情况2-Load等于1：马路已无额外的资源跑更多的汽车了：情况3-Load大于1：汽车都堵着等待进入马路：双核CPU如果有两个CPU，则表示有两条马路，此时即使Load大于1也不代表有汽车在等待：[Load==2，双核，没有等待]3.什么样的Load值得警惕？如下分析针对单核CPU【0.0 - 0.7]】：系统很闲，马路上没什么车，要考虑多部署一些服务【0.7 - 1.0 】：系统状态不错，马路可以轻松应对【等于1.0】：系统马上要处理不多来了，赶紧找一下原因【大于5.0】?：马路已经非常繁忙了，进入马路的每辆汽车都要无法很快的运行4.不同Load值说明什么问题？如下分析针对单核CPU的三种情况：情况1：1分钟负载 > 5，5分钟负载 < 1，15分钟负载 < 1举例：5.18 , 0.05 , 0.03短期内繁忙，中长期空闲，初步判断是一个“抖动”或者是“拥塞前兆”情况2：1分钟负载 > 5，5分钟负载 > 1，15分钟负载 < 1举例：5.18 , 1.05 , 0.03短期内繁忙，中期内紧张，很可能是一个“拥塞的开始”情况3：1分钟负载 > 5，5分钟负载 > 5，15分钟负载 > 5举例：5.18 , 5.05 , 5.03短中长期都繁忙，系统“正在拥塞”END链接：https://juejin.cn/post/7324576692872183808本文经授权转载，转载文章所包含的文字来源于作者。如因内容或版权等问题，请联系进行删除点击下方“阅读原文”，寻找职业新风向~