学习笔记—Grafana监控docker--mysql、redis的实战

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应用的代码里写的操作数据库脚本（有对应的表，对应的数据，对应的操作）