TPS 压不上去什么原因，怎么排查？
回答·6
最热
最新
- 首先，先确定是否存在系统资源瓶颈，必然 APP service 或者 DB CPU 内存不够（Java 的话是 检查 full gc）。 其次，如果系统资源没有瓶颈 ，再检查 系统配置是否正确 必然 线程池 ，DB 链接池。网络端口限制 这种。 最后，请检查 系统是否存在 外部依赖。比如 系统会等待第三方接口 提供数据。
- 带宽 在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。 2、连接池 可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如 Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。 （关于连接池的具体内容，可参考之前的博客：性能测试：连接池和线程）
- 这个原因比较多，压测整个链路上任何一个环节有瓶颈或者问题都有可能导致 1.首先是压力机压力不够，比如用我们笔记本基本压不到那么高 TPS， 所以我们公司有自己的压测平台，分布式集群压测。 2.网络带宽，单位时间内网络传输数据量过大，超过带宽处理能力 3.数据库连接数太少，最大连接数不够 4.Cpu，内存，磁盘硬件资源达到瓶颈 5.中间件 redis 也有可能存在瓶颈比如缓存穿透，缓存过期等等 6.存在大量线程阻塞，线程死锁等 7.中间件消息队列拥堵
- 1、网络带宽 在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。 2、连接池 可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如 Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。 3、垃圾回收机制 从常见的应用服务器来说，比如 Tomcat，因为 java 的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的 Eden 和 Survivor 区频繁的进行 Minor GC，老年代的 full GC 也回收较频繁，那么对 TPS 也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。 4、数据库配置 高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的 SQL 没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到 TPS。 5、通信连接机制 串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对 TPS 造成影响。 6、硬件资源 包括 CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。 7、压力机 比如 jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响 TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。 8、压测脚本 还是以 jemter 举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。 9、业务逻辑 业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。 10、系统架构 比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
- 服务器资源正常的情况下。别搞个十年前的奔腾当服务器来玩。↖(^ω^)↗。 主要分两种情况 第一：tps 小，rt 也小，资源利用率低 第二：tps 小，rt 大，资源利用率低 检查方向(前三点通用，后面根据两种情况着情分析) 1、脚本是否有问题(线程数设置是否合理、思考时间是否合理) 2、检查压测链路是否正常，负载是否到达指定压测服务器 3、检查有没有主动限制策略(如连接数限制，文件打开数量限制等) 1.4、多线程时，检查同步代码是否有问题； 2.4、检查网络是否已经达到瓶颈； 2.5、检查代码是否有问题(如：sql 写得有问题、算法设计效率低下、其它不必要的多余的操作等)
- 第一个原因：性能测试是从客户端向服务器发起一个请求，要经过网络传输，所以第一个原因可能是网络瓶颈，例如网络不稳定或带宽不够，那么同一时间点的请求量上不去，对服务请求的压力上不去那么这个 TPS 也就上不去。 第二个原因：客户端请求与服务器建立链接需要有连接池，连接池有两种 一种常见的是应用连接池，一种是数据库连接池。 应用连接池一个连接建立起来需要用连接通道，如果这个连接通道不够宽不够大，那么连接池可能不够用，导致服务器的性能利用不起来，也就是说应用连接池太小了。 第三个原因：数据库连接池，应用要与数据库交互时需要用到数据库连接池建立连接，如果数据库的连接池比较小的话，那这个查询速度也比较慢，数据库的综合能力跟不上，也会导致 tps 上不去。 第四个资源回收机制是否合理：连接建立起来要进行运算，运算要消耗资源，如果占用资源不能及时回收利用，会导致资源不够，这时 tps 也上不去。资源一个是硬件资源不够(cpu,内存) 通常所说的服务器 tps 值，默认的是 http、https 协议。但现实中还有 websocket 协议，如果同一个功能即能用 http 协议又能用 websocket 协议实现，那么 websocket 协议性能要比 http 协议大很多，tps 也就大很多 性能测试要求的并发量很高，有时需要有做分布式的压力机，如果压力机的资源不够，或压力机的分配不合理，那么 tps 也上不去，服务性的性能体现不出来 代码逻辑复杂，代码不够简洁 还有服务器的架构和缓存机制，也会影响 tps
相似问题
推荐关注
正在加载中...