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

首先咱们要先了解下TPS的具体含义：

TPS（Transaction Per Second）：每秒事务数，指服务器在单位时间内（秒）能够处理的事务数量，通常以request/second为单位。

下面就说说压测中为何TPS上不去的缘由，影响它的一些因素：

一、网络带宽

在压力测试中，有时候要模拟大量的用户请求，若是单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会形成网络资源竞争，间接致使服务端接收到的请求数达不到服务端的处理能力上限。

二、链接池

可用的链接数太少，形成请求等待。链接池通常分为服务器链接池（好比Tomcat）和数据库链接池（或者理解为最大容许链接数也行）。

三、垃圾回收机制

从常见的应用服务器来讲，好比Tomcat，由于java的的堆栈内存是动态分配，具体的回收机制是基于算法，若是新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS也是有必定影响的，由于垃圾回收其自己就会占用必定的资源。

四、数据库配置

高并发状况下，若是请求数据须要写入数据库，且须要写入多个表的时候，若是数据库的最大链接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会致使数据库事务处理过慢，影响到TPS。

五、通讯链接机制

串行、并行、长链接、管道链接等，不一样的链接状况，也间接的会对TPS形成影响。

六、硬件资源

包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

七、压力机

好比jmeter，单机负载能力有限，若是须要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就须要进行分布式压测来解决其单机负载的问题）。

八、压测脚本

仍是以jemter举个例子，以前工做中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，致使线程不足。
提到这个缘由，想表达意思是：有时候测试脚本参数配置等缘由，也会影响测试结果。

九、业务逻辑

业务解耦度较低，较为复杂，整个事务处理线被拉长致使的问题。

十、系统架构

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

十一、并发数

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

我记得我之前测文件上传的压力的时候带宽对tps的影响是很是大的，好比我传个文件大小5m，而测试机与服务器之间带宽才100m，这个时候即便并发数够大，可是因为带宽的限制，传送的数据就只有那么大，因此吞吐量怎么也上不去。你们也能够用传送数据比较大的接口作个测试，亲自体验下。

链接池的影响就很好理解了，记得以前测hdfs系统的时候，用的是mongodb，配置了链接池。好比咱们当时配置了100个链接池，那么当个人并发达到必定数量的时候，因为链接池已经达到最大值，其余请求只能处于等待的状态，那么即便服务器还能处理更多的请求，也因为没有更多的请求给服务器处理，所以这个时候tps也是上不去了。

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

 

 

分别是1个并发，2个并发，50个并发持续请求1min后tps的值，很直观的能够看到，若是在没有达到服务器处理瓶颈的时候，tps都是随着同时请求的数量上升而提升。因此有些时候咱们在寻找系统瓶颈的时候能够经过并发数的提升，而tps不升反而将的时候来判断系统的瓶颈在哪里。