昨晚在某个测试群看到有人问了一个问题:压力测试中TPS一直上不去,是什么缘由?稍微整理了下思路,列举性的简略回答了他的问题。html
这篇博客,就具体说说在实际压力测试中,为何有时候TPS上不去的缘由。若有遗漏或不对的,请评论区指出,不胜感激。。。java
先来解释下什么叫TPS:算法
TPS(Transaction Per Second):每秒事务数,指服务器在单位时间内(秒)能够处理的事务数量,通常以request/second为单位。数据库
关于性能测试的其余一些常见术语,可参考以前的博客:性能测试:常见术语浅析缓存
下面就说说压测中为何TPS上不去的缘由:服务器
一、网络带宽网络
在压力测试中,有时候要模拟大量的用户请求,若是单位时间内传递的数据包过大,超过了带宽的传输能力,那么就会形成网络资源竞争,间接致使服务端接收到的请求数达不到服务端的处理能力上限。架构
二、链接池并发
可用的链接数太少,形成请求等待。链接池通常分为服务器链接池(好比Tomcat)和数据库链接池(或者理解为最大容许链接数也行)。分布式
(关于链接池的具体内容,可参考以前的博客:性能测试:链接池和线程)
三、垃圾回收机制
从常见的应用服务器来讲,好比Tomcat,由于java的的堆栈内存是动态分配,具体的回收机制是基于算法,若是新生代的Eden和Survivor区频繁的进行Minor GC,老年代的full GC也回收较频繁,那么对TPS
也是有必定影响的,由于垃圾回收其自己就会占用必定的资源。
四、数据库配置
高并发状况下,若是请求数据须要写入数据库,且须要写入多个表的时候,若是数据库的最大链接数不够,或者写入数据的SQL没有索引没有绑定变量,抑或没有主从分离、读写分离等,
就会致使数据库事务处理过慢,影响到TPS。
五、通讯链接机制
串行、并行、长链接、管道链接等,不一样的链接状况,也间接的会对TPS形成影响。
(关于协议的链接,可参考以前的博客:HTTP协议进阶:链接管理)
六、硬件资源
包括CPU(配置、使用率等)、内存(占用率等)、磁盘(I/O、页交换等)。
七、压力机
好比jmeter,单机负载能力有限,若是须要模拟的用户请求数超过其负载极限,也会间接影响TPS(这个时候就须要进行分布式压测来解决其单机负载的问题)。
八、压测脚本
仍是以jemter举个例子,以前工做中同事遇到的,进行阶梯式加压测试,最大的模拟请求数超过了设置的线程数,致使线程不足。
提到这个缘由,想表达意思是:有时候测试脚本参数配置等缘由,也会影响测试结果。
九、业务逻辑
业务解耦度较低,较为复杂,整个事务处理线被拉长致使的问题。
十、系统架构
好比是否有缓存服务,缓存服务器配置,缓存命中率、缓存穿透以及缓存过时等,都会影响到测试结果。
PS:性能瓶颈分析不能单从局部分析,要综合起来,多维度分析问题缘由。上面列出的几点,可能有描述不当或者遗漏的,仅供参考。。。
若是有不许确的,请评论指正,谢谢!