一、配置grafana中的promethus
1、第一步:进入grafana后,先设置data source ,选择添加prometheus,并配置好地址,测试并保存(前提是prometheus是启动状态);
2、第二步:import一个对应的展示数据的模版:服务器数据模版、mysql数据模版
二、进入docker
1、Docker stats: 监控docker性能。注意:容器限制了内存大小,超过内存后报错
2、docker搭建cAdviso容器(自带容器)
监控分析流程:全局到局部
1、服务器资源–全局分析服务器
>usr%
>sys%
2、容器资源情况—usr%
根据分析需求去搭建对应的中间件的监控
3、mysql资源情况—专项分析
性能测试实战
一、性能场景设计
1、项目业务简介
2、项目架构
3、场景提取
>需要对应的性能指标
*甲方给定对应的指标
没有指标—公司自己评估系统的性能
常规的指标:TPS、RT(响应时间)、并发数
辅助的参考指标:错误范围(0~0.5%)
>场景设计
单场景:
。登录
。商品首页—列表出商品
多(混合)场景
。可以是一个或多个操作业务流程:登录-商品列出-商品详情—秒杀-退出
>比例场景
。基于多场景—精准流程:10%-50%-40%
压测前的准备:
>jmeter堆设置
1、win环境设置:/bin/jmeter.bat中设置 set HEAP=-Xms5g -Xmx5g
>端口设置:
压测实战一:
场景:获取商品列表
场景类型:单场景
测试类型:负载测试—不同负载(用户数)的性能表现
场景设置:ramp-up:持续时间是1s
场景名称/操作流程/场景详情/指标/备注
压测数据
用户数据/TPS/Error%/RT(ms)-平均/RT(ms)-90%/备注
性能分析:经过性能负载的事:整个列出商品的接口在容器监控下可以按到没有走redis。工作流程:直接从数据库mysql获取商品列表。
不同负载的趋势图:
grafana的监控图:
Cpu监控图
测试结果汇总
1、商品列出接口:tps在用户数在1500-2000范围内,TPS在2800
优化建议
结合分析:这个接口没有走redis
redis常用场景
读场景(查询接口)
补充知识点:
1、redis作用:让数据访问缓存,不访问数据库,减少对数据库的压力
哪些数据走redis:可以设置失效时间(开发去设置)
Token—需要账户密码去数据库做检验
高频业务数据—热点数据—当天的秒杀数据
哪些数据不适合走redis:只适合走mysql
需要事实查询
列表数据(订单)
2、jmeter的运行方式
jmeter.bat 在win环境运行(带页面)
jmeter.sh 在linux环境运行:
。在Mac环境运行的GUI模式
。在图像化linux环境的GUI模式
。jmeter命令模式
。Jmeter-server 分布式模式
**优化方案:这个接口走redis
开发解决:
回归测试:
2、问题:并发用户数在4000时,响应结果出现异常
分析:
1、先确认是测试机问题(查看jmeter右上角的黄色报错信息),还是项目服务器问题·
jmeter.log的问题:jmeter.heap 、jmeter.plus、socket
服务器问题: 500、404、断言(请求本身返回是否是200,响应有问题)
2、确认是项目服务器问题
3、去查看对应服务器log(查看到redis的连接池不够用)
4、优化redis连接池
二、压测实战二
**场景:**秒杀场景(登录-商品列出-商品详情—秒杀-退出)
**测试目标:**验证高并发下的秒杀接口的性能以及是否会出现超卖
场景类型:多场景
测试类型 :高并发–使用同步定时器
补充知识点:
同步定时器中“模拟用户组的数量”为0时,表示的是所并发的用户
分析:
线程数1001个都秒杀成功,但库存只有1000
测试结果:
出现超卖现象
优化建议:
*库存在mysql,使用mysql x锁;一个事务获取了一个x锁,其它事务不能去获取
*CAS 不使用锁
*redis预减库存
开发优化:
回归测试:
三、压测实战三
场景:在开发优化,测试回归过程中可能会引入新的bug
验证环境3.0.,优化升级到4.1
补充知识点:如何在项目中替换容器新版本:
1、stop老的容器(端口需要重用)
2、创建新的容器
分析:
1、使用浏览器访问项目的页面,看能不能访问
2、使用简单的指令查看资源情况 ,top
3、在项目空载的时候,cpu%==25%
4、cpu%>usr%>java进程高(pid 55730)(但实际上代码运行没有报错,不会有打印出服务器日志 docker logs -f --tail 100 miaosha)
5、miaoshao容器
6、使用iotop 看到有大量的磁盘写入操作
在外面查看秒杀容器
查看具体的进程的资源情况: top -H -p 55730
查看io的命令: pistat -p 50730 -t -d 1 3 或 iotop
7、写操作是miaosha进程miao.jar
8、进入秒杀容器内,docker exec 0t 53b /bin/bash
使用top 查看java进程—7jar
9、使用jstack 7 >miaosha.txt
10、正则查找 more +/miaosha miaosha.txt 去txt查看具体线程的描述
11、找到一个 文件上传任务在运行!
四、压测实战四–redis(结合压测实战一)
场景:高并发的用户数时
分析流程:先全局,后局部
1、聚合报告出现错误率=4.7%
2、经过查看结果树:响应报服务端异常
3、确定是服务器性能问题–下一步分析服务器性能
4、分析web应用服务器—miaosha容器
5、使用docker logs -f —tail 100 miaosha :看日志
6、分析redis的性能,连接池不够
>java代码里有配置文件
>redis应用本身的配置(两个配置,哪个小就以哪个为准)
7、了解redis
补充知识点:Redis:
Redis概述
内存数据库,纯内存操作,即把之前需要从数据库读取的诗句使用io,转化为读取内存数据
key-value数据库,非关系数据路
c语言编写,新能极高–如果传统方法安装:config,make
redis 支持数据持久化—必要的时候可以保存到磁盘
需要大量内存(网络带宽)
工作场景现象:登录的token保存到redis,如果redis挂了,登录失败了
redis性能指标:
性能指标:performance
内存指标:memory
基本活动指标:basic activity
持久性指标:persistence
错误指标:error
Redis配置:
1、临时配置—通过指令配置,重启应用就会失效(验证阶段时,使用临时方案)
Xx set 配置参数=10000
get 配置参数
1、进入redis容器: redis-cil -a sq
2、查看信息:info
3、CONFIG get maxclients 查看最大连接数
4、CONFIG set maxclients 5000 设置对答连接数
2、永久配置–修改对应配置文件 my.conf, redis.conf
/usr/local/redis.conf
#将容器内的文件复制到宿主机上
docker cp 容器id:/usr/local/redis.conf /root
3、修改redis本身连接数50000,压测之前的场景、一样报错,改回之前的10000配置
4、问下开发,你的springboot项目配置文件写多少
Maiosha3.0项目里面的文件配置:连接数时1000
5、优化下,项目配置文件 application.properties
Redis.poolMaxTotal=10000
Redis.poolMaxIdle=5000
6、回归设置后的版本
补充知识点:
redis的自测工具redis-benchmark,用来测试redis的性能,和业务没有关系
场景描述:
1、目前项目里****:miaosha应用去操作
2、直接跑开业务逻辑,直接测试组件的性能(配置参数所在服务器环境)
redis-benchmark -a sq -t get -c 100 -n 10000 :(容器内)模拟100个用户发送10000个请求
3、是不是所有的组件都要自测?
> 当你分析道这个组件可能有性能问题,可以去做这个操作
jmeter的jdbc取样器:直接去验证mysql组件,绕过业务层
性能测试正常流程:是不是用过业务层接口去执行的
Web应用的代码里写的操作数据库脚本(有对应的表,对应的数据,对应的操作)
实战五:
场景描述:验证redis是否击穿
场景1: 请求已有的商品
90%—267ms,redis使用率相对上去了
场景2: 请求没有的商品(首页没有展示这个商品)
90%—654ms ,redis使用率不会上了,mysql上去了,直接去db获取数据
补充知识点:
redis击穿、缓存雪崩
数据未加载到缓存中,或者缓存同一时间内大面积失效,从而导致所有请求都去查数据库,导致数据库cpu和内存负载过高,甚至宕机(一些服务器故障,包括服务器主机,数据库死锁或者DNS故障都可以称为宕机);举例:比如缓存中的key设置了统一的过期时间,而在国旗时间点,有大量的请求进来,这个时候redis中没有用户请的的资源,所以所有的请求会全部涌到数据库。如果数据库有报警监测的话,可能会保一下警,然后数据库就挂掉了。如果这时候把数据重新起来,redis上还是没有缓存这些内容,数据库还是会再一次被击垮。
**优化:**在redis添加一个空对象(代码层处理)
补充知识点:
秒杀操作时,如果路径和商品的id和token确定时,可以使用接口工具并发去秒。解决方法之一。采用了(动态秒杀地址)隐藏秒杀地址,例如在原来路径的基础上加上&verifyCode=验证码等,或添加一个加密值
补充知识点:
**redis调优操作:**redis的所有数据都在内存中,而内存又是非常宝贵的资源。
1、配置优化:
(1)linux配置优化:内存优化、THP、snappiness、ulimit设置
(2)redis配置优化:
设置最大物理内存
让键名保持简短
客户端timeout设置一个超时时间,防止无用的连接占用资源
检查数据持久化策略
优化AOF和RDB,减少占用CPU时间
监控客户端的连接
限制客户端的连接数
2、缩减健值对象
3、命令处理
4、缓存淘汰方案
rabbitMQ简介:
消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信。
RabbitMQ是使用Erlang语言开发的开源消息队列系统,基于AMQP协议来实现。AMQP协议更多用在企业系统内,对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量的要求还在其次。
**场景描述:**采用数据接口A----rabbitMQ—计费B
**测试需求:**需要测试B接口的性能
**方案一:**抓包B接口,使用jmeter直接压测B接口(不符合实际的生产性能)
**方案二:**使用MQ的生产者A接口产生消息,提供B接口消费
技术储备:
1、了解MQ
2、理解需求
3、如何使用MQ产生消息
4、采用数据接口A给MQ消息参数,不用的看B接口,只用jmeter模拟A接口高并发产生的队列的信息,就可以查看到B消费队列消息的性能
JMeter模拟AMQP
1、需要安装:amp-client-5.10.0.jar 和JMeterAMQP.jar,放到JMeter\lib\ext的目录下,重启JMeter
https://github.com/jlavallee/JMeter-Rabbit-AMQP.
2、用rabbitMQ自带的监控工具。监控MQ的内存,设置成服务器内存的0.5
进入MQ容器,rabbitmqctl
通常MQ测试是个链路测试,A接口—AMQP-- B接口
总结性能分析调优: