性能测试过程中遇到过哪些瓶颈？怎么定位分析性能瓶颈？

@性能瓶颈案例及定位方法，纯手打，转载请注明出处

性能测试过程中遇到瓶颈，怎么办

总结下这些年遇到最常见的性能瓶颈，响应时间不达标
一般测试：这里显示数据怎么这么慢？
开发：…

记住，测试不单单要发现问题，还要定位问题出现的原因,找出bug只是测试的责任，定位到问题才是测试能力的体现

话不多说，上干货

数据在哪

最简单的模型：

请求：客户端→应用服务器→数据库
响应：数据库→应用服务器→客户端

1. 正常使用中客户端发送请求是用户的网络，这个没什么必要去考虑，因为我们性能测试的目的检查的是服务器的性能，用户爱用啥就用啥，最多就是看下请求数据大小问题，发送的数据多了，要么压缩，要么就得分拆，别往一个请求里塞；
2. 数据库返回数据检查有没有慢查询
3. 应用服务器接收请求，访问数据库后处理数据，通俗来讲就是后端写的逻辑代码，新手总写一堆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 表名

码字累了，还有一些坑，慢慢更吧~