一、先了解以下基础概念1. 负载测试定义系统上不断增加压力直到响应时间或TPS达到一个拐点(超过预定的指标或者资源已经到了饱和状态不能再加压为止)主要目的是找到系统最大的负载能力(如响应时间超过要求限制或服务器资源占比已经到达预期要求已经到达顶点)为性能调优提供依据进行负载测试时需要逐步增加用户数(线程数50-100-150)来逐渐增加服务器的负载2. 线程组该怎么设置( 能写好、合适很考验压测经验)线程数 从多少开始写多少合适Ramp-Up时间(秒) 设置多少秒合适循环次数循环几次持续时间需要多长时间线程数(用户数)除非项目有明确要求不然都是依TPS为准(不看用户数的)很多场景有用户数的必须有TPS有TPS要求的不一定有用户数如果后台有流量看后台流量(1天有多少访问量)本身不知道有多少用户数慢慢使用梯度的方式压测(100-300-500-700)Ramp-Up时间先考虑如果网络、测试机、服务器都最佳的情况下ARamp-Up时间1s线程数100没问题那TPS也应该在100以上(1个请求至少有1个事务(TPS))实际95%响应时间在0.011s以上TPS为103.2s(在100左右的范围)如果有持续时间可能大于100(有的接口会跑多次) (1s请求100个用户至少100个TPS)BRamp-Up时间1s线程数500那TPS也应该在500以上(1个请求至少有1个事务)实际95%响应时间在1.32s以上实际上TPS为275.6s(1是TPS没达到2是响应时间没达到)C: 没加持续时间之前1s压测100线程组对应100左右TPS有压测缓存先不用管(停一会或者重启jmeter)得出结论线程数从底至高 100 (热启动1s线程组300或500不可取)正确设置热启动1s 代表jmeter工具1s时间发出去100请求保证测试机本身能够启动(不会挂掉)对象测试的是服务器例如5s启动500勾选永远负载测试持续时间一般100s(没有明确要求) 先保证本身工具能够启动起来后续持续时间300还是500s都没问题循环次数选择永远持续时间一般是300s没有严格要求只要启动起来就行趋势可以看到就行(如果有问题1分钟也有问题采集数据越大越能看到问题)这里设置100sTips如果加了持续时间有很多重复请求直到时间结束这时候TPS应该已经很大了延迟启动相当于定时器(定时运行)从当前压测时间开始计算多少s后开始运行暂时用不到3. 了解基础配置jmeter版本5.6服务器资源CPU(4核) 、 内存7G 、硬盘40GB压测前准备1. 堆设置win环境的jmeterjmeter.bat文件设置jmeter开始和最大堆内存为本机内存的70%性能指标(刚开始不知道TPS多少可不写)甲方给定对应的指标没有指标(你看下这个性能怎么样)俗称性能评估、性能摸底一些常规的指标(如下表)TPS RT(响应时间)、并发数二、场景一场景名称获取商品列表(http:192.168.197.130:7080/goods/Jlist)测试类型负载测试 --不同负载(用户数)的性能表现场景类型单场景场景设置 ramp-up 持续运行时间-对应(135710s)持续时间100s性能指标TPSRT/s错误率/%服务器资源(cpu和内存)备注30~0.5%80%商品列表线程组设置(持续加压)线程数(并发用户数)Ramp-Up时间(秒)循环次数持续时间1001永远1005005永远100100010永远100150015永远100压测数据用户数TPS/sRT(平均)/msRT(90%)/mserror/%服务器资源备注100215146520CPU21.6%内存38.2%5001818.02654740CPU23.3%内存36.4%10001654.657112060CPU57.1%内存41.3%15001808.776218800CPU29.9%内存51.0%2000771.3230256980.20CPU68.0%内存42.7%100并发下的数据500并发下的数据1000并发下的数据1500并发下的数据2000并发下的数据docker下监控CPU和内存利用率性能分析流程性能现象(TPS、RT、错误率)—全局定位(CPU、内存、磁盘、网络)—局部分析(进程、配置、代码层、架构层)通过性能现象可以先了解(TPS、RT、错误率)有没有达标—例如CPU—局部对某一个进程分析例如生病(感冒)先讲述症状—验血或拍片子—医生根据片子再做局部分析—根据分析后的结果进行开药其他1面试中问TPS要求多少没有特定值需要看场景在单场景和混合场景下的TPS是不一样的(单场景单接口TPS很大多场景(多接口)TPS很底)其他2TPS压测完分析第一种到了一定的拐点呈现类似N形状(这个时间段有没有大量用户退出)如果没有跳过到第二种第二种是大量用户退出呈现M形状(正常退出)负载为0(可以分析性能问题了)性能分析通过聚合报告查看(RT TPS 错误率%)RT时间过长 ------最大并发应该在1300左右查看服务器资源情况cpu、内存80%符合预期指标压测过程中可以查看对应的容器使用情况 web应用容器mysql容器为了更精准去确认最大TPS或者最大用户数可用细化用户数再验证性能定论商品列出接口的性能最大TPS在2100左右对应的用户数在100左右在符合性能指标要求范围内最大用户数可以在300左右评审(一般有两种情况)性能指标OK领导或对应人员感觉TPS太低TPS没有达到要求需要提高TPS(改进需求)性能优化建议根据分析这个场景请求只走mysql容器 没有走redisredis作用让数据访问缓存不访问数据库减少堆数据库的压力哪些数据可以走redis设置失效时间(开发代码配置)token–需要账户密码去验证数据库做检验高频业务数据–热点数据—当天秒杀数据哪些数据不适合走redis适合走mysql需要实时查询列表数据根据业务场景这个数据可以优化数据可以存缓存使用redis可以加快读取数据性能调优需要优化这个场景走redis开发解决修改代码开发给迭代计划-时间优化版本列出商品接口(优化后)http:192.168.197.130:7080//goods/redis/Jlist商品列表线程组设置(持续加压)线程数(并发用户数)Ramp-Up时间(秒)循环次数持续时间5005永远100100010永远100150015永远100200020永远100性能版本回归1.0.2优化后的压测数据用户数TPS/sRP(平均)/msRT(90%)/mserror/%服务器资源备注5005698.6851270CPU51.7%内存47.2%10005479.91723120CPU44.1%内存48.2%15002308.760213610CPU57.8%内存50.8%2000265.7289961790.77%CPU72.8%内存62.6%2000并发下的数据性能分析流程–先全局后局部聚合报告出现错误率0.77%不符合预期查看结果树出现大量报错如下HTTPHC4Impl$JMeterDefaultHttpClientConnectionOperator.connect(HTTPHC4Impl.java:409)at org.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocketjavanet.BindException:Addredd alreadyinuse: connect确定是服务器性能问题–下一步分析服务器性能压测机本身端口号问题(windows本身提供的端口数量有限有可能导致接口请求时端口被占用windows默认提供的端口是1024-5000并且四分钟来循环回收他们就导致我们在短时间内跑大量压测请求时将端口占满)打开注册表winR输入regedit(计算机\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters)添加新的DWORD名字分别为MaxUserPort和TcpTimedWaitDelay分别输入数值数据65534和30基数选择十进制增大可配置的tcp连接端口数减小处于TIME_WAIT状态的连接的生存时间可以解决的问题1. 扩大端口数量2. 提高端口使用率参考windows下Jmeter压测端口占用问题配置完成后需要重启电脑才会生效再次压测查看结果如果还是没有效果再往下继续分析分析web应用服务器 miaosha容器使用动态查看容器指令(容器前3位c5c)docker logs c5c -f --tail 300 或 docker logs -f --tail 300 miaosha看日志报错如下redis.clients.jedis.exceptions.JedisException: Could not get a resource from the pool分析redis的性能连接池不够(临时更改不需要重启容器重启容器就失效)redis应用的配置文件设置需要确认如果不够进行优化进入redis容器 docker exec -it 860 /bin/bash进入redis客户端redis-cli -a sq获取最大连接数 config get maxclients更改最大连接数config set maxclients 50000如果更改了压测之后还是报一样的错误查看tomcat连接数永久化配置修改配置文件 redis.conf进入redisdocker exec -it redis /bin/bash安装vi命令atp-get updateapt-get install -y vim安装成功后可以从外面进入redis容器更改配置文件docker exec -it redis vi /usr/local/redis.conf按esc/maxclients 进行搜索maxclients更改50000重启redis容器使其生效docker restart redis再次进行压测修改redis本身的链接数50000压测之前的场景一样报错改回之前的10000配置docker exec -it redis vi /usr/local/redis.conf重启redis容器使其生效docker restart redis备注如果上一步临时修改redis最大连接池有效果就去配置永久化配置如果没有效果就不用执行第8步了问下开发你的springboot项目配置文件写多少本身的应用服务器有可能运行参数有限制(在 application.properties 文件内修改永久修改)application.properties这个文件不一定有springboot有配置参数的文件(找不到可以找开发要配置路径(权限很高))文件内容如下优化两个参数如下redis.poolMaxTotal10000redis.poolMaxIdle5000更改完后需要docker重新打镜像进行压测先把之前的miaosha容器停止docker stop miaosha再执行下面语句dockerrun-id--namemiaosha3.1-p7080:7080--linkmysql--linkrabbitmq--linkredis:myRedis-v/etc/localtime:/etc/localtime:ro registry.cn-hangzhou.aliyuncs.com/sqqdcl/miaosha:3.1回归测试(等待30s之后再进行压测容器彻底起来)列出商品接口(优化后)http:192.168.197.130:7080//goods/redis/Jlist商品列表线程组设置(持续加压)线程数(并发用户数)Ramp-Up时间(秒)循环次数持续时间5005永远100100010永远100150015永远100200020永远100300030永远100回归结果用户数TPS/sRP(平均)/msRT(90%)/mserror/%服务器资源备注5005704.6541250CPU64.3%内存37.3%100043442171320CPU63.0%内存40.9%15004514.32173190CPU37.5%内存42.2%20005065.23537400CPU33.1%内存46.4%3000234884714580CPU68.2%内存52.3%3500390.6330867660.20CPU64.3%内存58.7%500并发下的聚合报告数据1000并发现下的聚合报告数据1500并发现下的聚合报告数据2000并发现下的聚合报告数据3000并发现下的聚合报告数据3500并发现下的聚合报告数据TPS和RT的关系 TPS很大很大RT一定很小单接口场景最关注的是TPS极少关注最大用户数用户数在混合业务场景下比较多性能定论接口名称最大TPS错误率最大并发用户数商品列出5700左右03200左右建议虚拟机启动后容器再次重启后压测效果不错