@性能瓶颈案例及定位方法,纯手打,转载请注明出处
性能测试过程中遇到瓶颈,怎么办
总结下这些年遇到最常见的性能瓶颈,响应时间不达标
一般测试:这里显示数据怎么这么慢?
开发:…
记住,测试不单单要发现问题,还要定位问题出现的原因,找出bug只是测试的责任,定位到问题才是测试能力的体现
话不多说,上干货
数据在哪
最简单的模型:
请求:客户端→应用服务器→数据库
响应:数据库→应用服务器→客户端
- 正常使用中客户端发送请求是用户的网络,这个没什么必要去考虑,因为我们性能测试的目的检查的是服务器的性能,用户爱用啥就用啥,最多就是看下请求数据大小问题,发送的数据多了,要么压缩,要么就得分拆,别往一个请求里塞;
- 数据库返回数据检查有没有慢查询
- 应用服务器接收请求,访问数据库后处理数据,通俗来讲就是后端写的逻辑代码,新手总写一堆if做判断,老手已然调用方法风生水起
网络分析定位
出现响应时间过长,第一步排查网络
1、调出服务器的access.log
2、通过里面的request_time与upstream_response_time进行对比
3、如果request_time远大于upstream_response_time 则说明请求网络带宽不足,这时候需要增加带宽或者压缩传输数据或者分拆请求数据
解释一下
request_time:
作用是收到请求开始到发送完响应数据这个时间
upstream_response_time:
从与服务器建立连接到接收完数据并关闭连接的时间
cpu占用率高居不下
那如果没有问题怎么搞?
那就要看下服务器的cpu了
top之后 按Shift+P键就能按cpu占用情况排序啦
如果发现有进程占用巨高,那么,恭喜你,你找到原因了
我之前遇到有个服务的进程居然cpu占用率高达70%,然后另一个服务正是对应响应时间变慢的功能接口,妥妥的架构不合理啊,最后解决办法是搭建了分布式服务器(当然这是开发干的活,我只是好奇咨询了一下),走到现在来看,可能微服务架构会更好一点
缓存过多也会导致服务器响应变慢
1)按正常走下去,cpu如果么得问题,那内存也得瞅瞅
查看内存用到命令 free -m
total是总内存
used是已用内存
free是可用内存
2)再用top查看下内存,大概计算一下是不是等于刚查到的used的值
3)为什么这样做,因为我遇到过这种情况,已用内存是12GB,但是top查出来的内存总和大概9GB,那剩下的3GB呢,跑哪去了?
4)用cat /proc/meminfo查看内存更加详细的信息
我发现不见了的3GB近乎全部在Slab(Slab是用于存放内核数据结构缓存)下面;
5)通过slabtop命令查看这部分内存的使 用情况,发现大部分内存被dentry_cache占用了;
把问题反馈给开发后,开发通过释放Slab占用的cache内存空间解决
解决命令需要sudu的权限
sync
sudo sysctl -w vm.drop_caches=3
sudo sysctl -w vm.drop_caches=0 #recovery drop_caches
数据库慢查询
遇到过一个问题,表中没有创建索引导致响应时间长,CPU占用变高
有个接口120的tps,cpu使用率却高达90%,响应时间大于1秒。
定位问题
进入mysql的命令模式
set global slow_query_log = on; 开启慢查询日志
set long_query_time = 1; 设置慢查询时长为1s
set globle log_output = 路径/文件名 设置慢查询日志文件存放路径
意味着查询超过1s的sql语句写入慢查询日志
通过进入数据库定位发现该语句没有创建索引
解决后tps上升到240,响应时间下降到280ms左右。
问:怎么看有没有创建索引?
答:mysql命令模式输入SHOW INDEX FROM 表名
码字累了,还有一些坑,慢慢更吧~