Jmeter 性能-TPS上不去原因分析

1、TPS上不去的原因

①网络带宽

当你模拟大量用户发起请求的时候，单位时间内传递的数据包过大，超过了带宽的传输能力，造成网络资源竞争

间接的就导致了服务器接收的请求数达不到服务器的处理能力上限，tps值自然就不会上升。

②连接池

连接池一般主要有两种，应用服务器连接池配置 和 数据库连接池配置

配置太小，连接数被占满了，新的连接只能等待，tps值也就自然不会再上升。

③垃圾回收机制

JVM的垃圾回收GC都是基于算法的，如果新生代的Eden和Survivor区频繁的进行Minor GC

老年代的full GC也回收频繁，那么对TPS就会有影响，因为垃圾回收本身占用一定的资源。

④数据库配置

对数据库进行的读、写数据操作时，连接数、库表索引、读写分离、数据库主从方案等都有关系

⑤通信连接机制

通信连接我们常见的有 串行、并行、长连接、管道连接等

⑥硬件资源

服务器硬件资源消耗过高，服务器处理不过来，tps也就上不去了

⑦压力机

用Jmeter做性能测试，一台机器并不能无上限的虚拟并发用户，想要高并发，可能机器根本虚拟不出预期的用户数，服务器tps自然也就不会上升。

⑧压测脚本

都知道性能测试，脚本是一方面，还要有性能场景设计，如果脚本+场景设计不合理，也不会达到预期的效果。

⑨业务逻辑

如果被测系统业务耦合度非常高，一个功能相当于在测试整个系统了，这样的系统，tps也高不起来。

⑩系统架构

现比较常见的都是在服务器上会增加缓存机制，缓存服务器配置、命中率、缓存穿透、缓存过期等等，都会影响性能结果。

2、TPS上不去监控/分析思路

①首先去Linux服务器端，通过iftop命令结合dstat命令去看看网络是否稳定，带宽够不够，发的请求有没有到服务器

②然后看不断的加线程或者请求，用top命令看看load值，平均负载和CPU，内存是否有变化

如果变化不大有没有可能是Tomcat服务器的连接池太小导致，发送的请求被限制了，看Tomcat是不是用的bio，改为nio并行的io看看tps的变化大不大

③如果没有以上原因，接着去看是不是数据库连接池太小，然后接着通过

1. jmap -head pid

2. jstat -gcutil pid 1000

3. vmstat 1 10

命令去看看是否有频繁的fullgc和中断，上下文切换，如果有频繁的垃圾回收也会导致tps抖动厉害上不去

包括是否有频繁的上下文切换，内核被消耗，因为频繁的io读取也会导致上下文切换过高，从而资源飙升，导致tps上不去

所以通过dump一下当前的线程的堆栈信息去看看有没有阻塞之类的来进行定位

④包括会去看是不是压力机本身压力就不够，这种通过分布式去压测

⑤如果这些都做好了，看一下是不是压测脚本里面事务比较复杂，并且加了思考时间之类的。

⑥有必要的话也要通过Prometheus+grafana进行全局的监控

如果通过skywalking去监控每个节点所耗费的时间来具体定位分析

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。