tps上不去，到底有哪些方面的原因呢，我这里大概给大家整理了一下，有以下10个方面的可能原因。
1、网络带宽：当你模拟大量用户发起请求的时候，单位时间内传递的数据包过大，超过了带宽的传输能力，造成网络资源竞争，间接的就导致了服务器接收的请求数达不到服务器的处理能力上限，tps值自然就不会上升。
2、连接池：连接池一般主要有两种，应用服务器连接池配置 和 数据库连接池配置，配置太小，连接数被占满了，新的连接只能等待，tps值也就自然不会再上升。
3、垃圾回收机制：JVM的垃圾回收GC都是基于算法的，如果新生代的Eden和Survivor区频繁的进行Minor GC， 老年代的full GC也回收频繁，那么对TPS就会有影响，因为垃圾回收本身占用一定的资源。
4、数据库配置：对数据库进行的读、写数据操作时，连接数、库表索引、读写分离、数据库主从方案等都有关系
5、通信连接机制：通信连接我们常见的有 串行、并行、长连接、管道连接等
6、硬件资源： 服务器硬件资源消耗过高，服务器处理不过来，tps也就上不去了
7、压力机：用jmeter做性能测试，一台机器并不能无上限的虚拟并发用户，想要高并发，可能机器根本虚拟不出预期的用户数，服务器tps自然也就不会上升。
8、压测脚本：我们都知道，性能测试，脚本是一方面，还要有性能场景设计，如果脚本+场景设计不合理，也不会达到预期的效果。
9、业务逻辑：如果被测系统业务耦合度非常高，一个功能相当于在测试整个系统了，这样的系统，tps也高不起来。
10、系统架构：现在比较常见的都是在服务器上会增加缓存机制，缓存的服务器配置、命中率、缓存穿透、缓存过期等等，都会影响性能结果。
tps如果上不去我的监控和分析思路：
1、首先我会去Linux服务器端通过iftop命令结合dstat命令去看看网络是否稳定，带宽够不够，发的请求有没有到服务器
2、然后看不断的加线程或者请求，用top命令看看load值，平均负载和CPU，内存是否有变化，如果变化不大有没有可能是Tomcat服务器的连接池太小导致，发送的请求被限制了，我会去看看Tomcat是不是用的bio，改为nio并行的io看看tps的变化大不大
3、如果没有以上原因我会接着去看是不是数据库连接池太小，然后接着会通过jmap -head pid和jstat -gcutil pid 1000、vmstat 1 10命令去看看是否有频繁的fullgc和中断，上下文切换，如果有频繁的垃圾回收也会导致tps抖动厉害上不去，包括是否有频繁的上下文切换，内核被消耗，因为频繁的io读取也会导致上下文切换过高，从而资源飙升，最终导致tps上不去，所以我会通过dump一下当前的线程的堆栈信息去看看有没有阻塞之类的来进行定位
4、包括会去看是不是压力机本身压力就不够，这种我会通过分布式去压测
5、如果这些都做好了，我会去看一下是不是我的压测脚本里面事务比较复杂，并且加了思考时间之类的。
6、当然有必要的话我也会通过Prometheus+grafana进行全局的监控，如果通过skywalking去监控每个节点所耗费的时间来具体定位分析