【转】性能测试,影响 TPS 的一些因素

首先我们要先了解下TPS的具体含义:

TPS(Transaction Per Second):每秒事务数,指服务器在单位时间内(秒)可以处理的事务数量,一般以request/second为单位。

下面就说说压测中为什么TPS上不去的原因,影响它的一些因素:

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、系统架构

比如是否有缓存服务,缓存服务器配置,缓存命中率、缓存穿透以及缓存过期等,都会影响到测试结果。

11、并发数

下面就拿具体的例子来说明一下

我记得我以前测文件上传的压力的时候带宽对tps的影响是非常大的,比如我传个文件大小5m,而测试机与服务器之间带宽才100m,这个时候即使并发数够大,但是由于带宽的限制,传送的数据就只有那么大,所以吞吐量怎么也上不去。大家也可以用传送数据比较大的接口做个测试,亲自体验下。

连接池的影响就很好理解了,记得之前测hdfs系统的时候,用的是mongodb,配置了连接池。比如我们当时配置了100个连接池,那么当我的并发达到一定数量的时候,由于连接池已经达到最大值,其他请求只能处于等待的状态,那么即使服务器还能处理更多的请求,也由于没有更多的请求给服务器处理,因此这个时候tps也是上不去了。

再举一个就是并发数对tps的影响:
下面有几张图

 

 


分别是1个并发,2个并发,50个并发持续请求1min后tps的值,很直观的可以看到,如果在没有达到服务器处理瓶颈的时候,tps都是随着同时请求的数量上升而提高。
所以有些时候我们在寻找系统瓶颈的时候可以通过并发数的提高,而tps不升反而将的时候来判断系统的瓶颈在哪里。

 

posted @ 2018-06-21 17:45 yanghj 阅读(...) 评论(...) 编辑 收藏