性能测试中常见缺陷及TPS上不去的原因浅析

性能测试中TPS上不去的原因浅析及常见缺陷

一、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造成影响。

丢包：数据在网络上是以数据包的形式传输的，如果丢包，则可能造成报错或异常的情况；

3、应用

（1）、JVM

堆内存分配：根据系统硬件条件来进行合理的堆内存分配，一般来说JVM的堆内存分配不要超过系统内存的25%较好；

垃圾回收算法：JAVA的动态垃圾回收机制，是基于不同的几种回收算法来进行的，根据

具体的情况，选择合适的垃圾回收策略；

OOM：即内存溢出（out of memory），这个算是性能测试中很常见的一个问题，通常

是由于代码问题造成的内存泄漏、GC不够彻底、内存被耗尽引起；

（2）、代码逻辑

常见的情况有不合理的线程引用和内存分配；

4、配置

版本：在性能测试过程中，一定要确保被测系统的版本和实际生产保持一致，否则由于版

本不同带来的些许差异可能会对性能测试带来很大的偏差和影响；

底层配置：涉及到操作系统、服务器等硬件的一些配置方式不合理，带来的性能瓶颈；

参数配置：系统架构设计中，各个不同的参数配置带来的性能瓶颈；

5、数据库

索引：索引的存在就像一个标签目录一样，在执行数据库操作时提供更为快速的执行效率，减少磁盘IO操作和执行的数据库系统时间；

锁：为了保证事务的原子性和隔离性，有了锁的存在，但有时候由于某些原因造成的表锁，也是性能瓶颈的一种表现；

表空间：不合理的表空间设计，导致的数据库性能问题；

慢SQL：慢SQL会导致数据库操作时间变长，增加IO读写以及引起一些列的资源竞争等问题，常见的慢SQL原因如下（以MySQL为例）：

数据量：对同一张表来说，1W条数据和1000W条数据，对其进行操作时的性能表现也

是不同的，因此在性能测试时对于数据的正确性可用性，以及数据量也是需要重点关注的；

6、中间件

超时：设置合理的请求或响应超时时间，是很有必要的，这点要根据具体的业务场景和系

统架构来考虑，具体的超时时间，建议进行配置测试来设定；

线程池：之前的博客介绍过线程池的相关资料，线程池配置太小，很容易被使用完，太大

的话又浪费资源，合理的线程池，建议进行配置测试来确定；

缓存策略：缓存的优点是减少请求响应过程中的传输时间，但有时候在高并发情况下，缓

存很容易失效而导致缓存穿透，瞬间对服务端带来很大的压力；

最大连接数：关于连接数，之前的博客也介绍过，合理的连接数配置是很重要的，否则连

接数太少容易导致队列等待、超时，连接数太多则浪费了系统资源；

通信实现方式：同步（sync）和异步（Async）；

负载均衡策略：现在很多的系统都进行了服务集群，随之而来的就是负载均衡策略的实现，如果负载均衡不够“均衡”，在大数量的冲击下，容易导致某些服务的异常或者挂起；