卑微小测试的一天------jmeter压测（实战踩坑&故障分析）

踩坑记录

之前参与的压测工作都是执行者，根据别人的方案，别人的想法去执行压测脚本即可，没有主导过大型项目的压测，所以这次在压测过程中也算是磕磕绊绊，还好开发同事是个有经验的老司机，遇到的问题基本都能帮忙解答

一号坑-----无法达到预期并发

最开始进行压测的并发设置从80-200时，服务相关接口请求量基本维持在一个量级，但是服务器的CPU内存等维持在一个很低的数值，反倒是压测机的CPU 不管设置多少并发，CPU都是100 %
一开始以为发压机的原因，因为申请的机器是容器环境，不是实体机，认为申请的服务器资源可能存在虚标。

针对这个猜想，我重新申请了发压机，使用分布式的方式进行加压。但是采用这种方式后还是无法将并发提高。所以这个猜想不成立

后面将情况反馈给研发同事，研发同事说，我们的请求是通过运维团队的“高防”服务的过滤后转发到我们服务的。有可能是这个服务的性能不好。

对于这个猜想，我们调整了请求的方式，先使用单机，直接请求服务的单台IP，发现单台IP能统计到的请求量都远大于之前的请求量

好吧！就是这个高防服务的原因。但是我们的系统是海外的系统，海外的情况很复杂，黑产也比较 猖獗，我们必须要借助高防服务来帮助我们拦截掉一部分的请求。

最后在运维的协助下，我们重新配置了一个本地域名，通过这个域名去请求的话，就能绕过高防服务，而且这个本地域名请求用的是Http，相较于https也有一定的性能提升。这里插入两个知识点，一个是http和https的，还有一个就是本地域名访问的原理

• HTTP 和HTTPS 的区别

HTTPs链接和HTTP链接都建立在TCP协议之上。HTTP链接比较单纯，使用三个握手数据包建立连接之后，就可以发送内容数据了
它也采用TCP协议发送数据，所以它也需要上面的这三步握手过程。而且，在这三步结束以后，它还有一个SSL握手。
所以，HTTPs肯定比HTTP耗时，这就叫SSL延迟。

• 域名绑定

对于一些经常要访问到的网站，我们可以通过在Hosts中配置域名和IP的映射关系，这样当我们输入要访问的虚拟域名，计算机就能够很快地解析出IP，而不必请求网络上的DNS服务器。

这样就可以直接验证后端服务的相关性能，而不用去排查网络问题

二号坑----服务没有压测到瓶颈

越过一号坑后，我们将一些性能较好的接口TPS已经压测到2W+了，但是在服务器和压测机性能指标都还没有达到瓶颈时，却再也压不上去了。

这时我们又引入了另一个猜想，那就是机房网络上限。为了验证这个猜想，我们直接在本地又启动了一个线程，和远程机房的压测脚本同时请求服务，发现请求量确实又增加。

最后求证运维同事，运维同事帮忙查询了网络带宽后，确认是因为当地机房的网络限制，带宽已经满了，所以本地的请求就无法再提升了。

三号坑----线上只能“读压测”

因为一些原因，系统无法将一些生产数据隔离，导致线上无法进行“写压测”，如果系统有相关支撑的话，理论上我们可以在生产环境加上一些白名单，或者在请求中添加一些特定的参数，让压测产生的数据进入一个与生产环境隔离的数据库，这样就能在原有服务器资源的条件下，模拟“写压测”。
我们还可以回放线上流量，更加真实的模拟线上的请求。当然流量回放也有很多问题需要去面对，比如登陆失效，数据降噪等问题。我认为这会是后续压测的一个主流的方向吧！

四号坑----临近上线，发现活动页面漏测了

在我们将压测服务器释放并且将压测报告整理汇报之后，发现运营新配置的活动页面有两个重要的接口没有压测，这个最后只能再临近封版前再补充一轮压测。

这个情况当时确实很无奈，因为当时获得的信息是活动页面为首页，然后运营通知有个活动落地页面，最后只能查看页面接口再分析哪些接口需要压测

这个也算是信息没有及时同步，导致很仓促，好在结果还算OK。这里算是经验教训吧，一定要及时同步信息，不关是不是你的疏忽，提醒相关同事注意事项也是很有必要的。

总结

经过这次大促的压测，自己对压测和系统 的理解也算是深入一些了，当然这还远远不够，我认为一个压测工程师的话，不仅需要发现系统 的性能瓶颈，更重要的是针对这些性能的瓶颈，给出改进的意见。

最后附上一些从网上收录的性能问题分析步骤：

故障分析

对性能问题进行粗略评估，过滤一些因为低级的业务逻辑导致的性能问题。譬如：
1、线上应用日志级别不合理，可能会在大流量时导致CPU 和磁盘的负载飙高，这种情况调整日志级别即可；
2、了解应用的的总体架构，比如应用的外部依赖和核心接口有哪些，使用了哪些组件和框架，哪些接口、模块的使用率较高，上下游的数据链路是怎么样的等；
3、了解应用对应的服务器信息，如服务器所在的集群信息、服务器的CPU/内存信息、安装的Linux 版本信息、服务器是容器还是虚拟机、所在宿主机混部后是否对当前应用有干扰等；

CPU 相关指标异常的分析思路是什么？

1、CPU 利用率：如果我们观察某段时间系统或应用进程的CPU 利用率一直很高（单个core 超过80%），那么就值得我们警惕了。我们可以多次使用jstack 命令dump 应用线程栈查看热点代码，非Java 应用可以直接使用perf 进行CPU 采采样，离线分析采样数据后得到CPU 执行热点（Java 应用需要符号表进行堆栈信息映射，不能直接使用perf 得到结果）。
2、CPU 平均负载：平均负载高于CPU 数量70%，意味着系统存在瓶颈点，造成负载升高的原因有很多，在这里就不展开了。需要注意的是，通过监控系统监测平均负载的变化趋势，更容易定位问题，有时候大文件的加载等，也会导致平均负载瞬时升高。如果1 分钟/5 分钟/15 分钟的三个值相差不大，那说明系统负载很平稳，则不用关注，如果这三个值逐渐降低，说明负载在渐渐升高，需要关注整体性能；
3、CPU 上下文切换：上下文切换这个指标，并没有经验值可推荐（几十到几万都有可能），这个指标值取决于系统本身的CPU 性能，以及当前应用工作的情况。但是，如果系统或者应用的上下文切换次数出现数量级的增长，就有很大概率说明存在性能问题，如非自愿上下切换大幅度上升，说明有太多的线程在竞争CPU。CPU 上的的一些异动，通常也可以从线程上观测到，但需要注意的是，线程问题并不完全和CPU 相关。与线程相关的指标，主要有下面几个（均都可以通过JDK 自带的jstack 工具直接或间接得到）：

• 应用中的总的线程数；
• 应用中各个线程状态的分布；
• 线程锁的使用情况，如死锁、锁分布等；

关于线程，可关注的异常有：

线程总数是否过多。过多的线程，体现在CPU 上就是导致频繁的上下文切换，同
时线程过多也会消耗内存，线程总数大小和应用本身和机器配置相关；
线程的状态是否异常。观察WAITING/BLOCKED 线程是否过多（线程数设置过多
或锁竞争剧烈），结合应用内部锁使用的情况综合分析；
结合CPU 利用率，观察是否存在大量消耗CPU 的线程。

常见的内存问题总结如下：

系统剩余内存/可用不足（某个进程占用太多、系统本身内存不足），内存溢出；
内存回收异常：内存泄漏（进程在一段时间内内存使用持续走高）、GC 频率异常；
缓存使用过大（大文件读取或写入）、缓存命中率不高；
缺页异常过多（频繁的I/O 读）；
Swap 分区使用异常（使用过大）；

如何判断磁盘的指标出现了异常？

当磁盘I/O 利用率长时间超过80%，或者响应时间过大（对于SSD，从0.0x 毫秒到1.x 毫秒不等，机械磁盘一般为5ms~10ms），通常意味着磁盘I/O 存在性能瓶颈；
如果%util 很大，而rkB/s 和wkB/s 很小，一般是因为存在较多的磁盘随机读写，最好把随机读写优化成顺序读写，（可以通过strace 或者blktrace 观察I/O 是否连续判断是否是顺序的读写行为，随机读写应可关注IOPS 指标，顺序读写可关注吞吐量指标）；
如果avgqu-sz 比较大，说明有很多I/O 请求在队列中等待。一般来说，如果单块
磁盘的队列长度持续超过2，一般认为该磁盘存在I/O 性能问题。

一般来说，应用层的网络瓶颈有如下几类：

集群或机器所在的机房的网络带宽饱和，影响应用QPS/TPS 的提升；
网络吞吐出现异常，如接口存在大量的数据传输，造成带宽占用过高；
网络连接出现异常或错误；
网络出现分区。

分析问题常用的工具

• CPU：top、vmstat、pidstat、sar、perf、jstack、jstat；
• 内存：top、free、vmstat、cachetop、cachestat、sar、jmap；
• 磁盘：top、iostat、vmstat、pidstat、du/df；
• 网络：netstat、sar、dstat、tcpdump；
• 应用：profiler、dump 分析。