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
相似问题
推荐关注
正在加载中...