①网络带宽
当你模拟大量用户发起请求的时候,单位时间内传递的数据包过大,超过了带宽的传输能力,造成网络资源竞争
间接的就导致了服务器接收的请求数达不到服务器的处理能力上限,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的变化大不大
③如果没有以上原因,接着去看是不是数据库连接池太小,然后接着通过
jmap -head pid
jstat -gcutil pid 1000
vmstat 1 10
命令去看看是否有频繁的fullgc和中断,上下文切换,如果有频繁的垃圾回收也会导致tps抖动厉害上不去
包括是否有频繁的上下文切换,内核被消耗,因为频繁的io读取也会导致上下文切换过高,从而资源飙升,导致tps上不去
所以通过dump一下当前的线程的堆栈信息去看看有没有阻塞之类的来进行定位
④包括会去看是不是压力机本身压力就不够,这种通过分布式去压测
⑤如果这些都做好了,看一下是不是压测脚本里面事务比较复杂,并且加了思考时间之类的。
⑥有必要的话也要通过Prometheus+grafana进行全局的监控
如果通过skywalking去监控每个节点所耗费的时间来具体定位分析
行动吧,在路上总比一直观望的要好,未来的你肯定会感谢现在拼搏的自己!如果想学习提升找不到资料,没人答疑解惑时,请及时加入群: 786229024,里面有各种测试开发资料和技术可以一起交流哦。
最后: 下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保证100%免费】
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。