13年经验，性能测试-电商系统TPS+上不去原因分析（详细）

网易测试开发猿

695人浏览 · 2026-01-23 16:11:58

网易测试开发猿 · 2026-01-23 16:11:58 发布

目录：导读

前言

1、电商系统tps

怎么计算得出tps指标？
1）第一个通过运维那边给的生产数据，看一下生产进件有多少，计算得来的，如果没有生产数据，或者不过就看如下的方法

2）第二个就是根据最近一个月的实际访问数据，比如每天调用了多少个接口，调用了哪些接口，把比例列出来

举个例子，比如我们yshop系统，从一个月时间，最高的一天调用接口数量最高为100万次，那么tps的计算公式如下：
tps = 1000000/24*3600=11.57/sec ==》这是通用的tps

比如这100万次请求里面

登录请求比例：40%   那么登录接口的标准tps=11.57*40% = 4.63/sec
退出请求比例：20%   那么退出接口的标准tps=11.57*20% = 2.31/sec
添加商品比例：20%   那么添加商品接口的标准tps=11.57*20% =  2.31/sec
查询商品比例：10%   那么查询商品接口的标准tps=11.57*10% = 1.16/sec
修改商品比例：10%   那么修改商品接口的标准tps=11.57*10% = 1.16/sec

如上是通用的tps模型，除了上面的通用tps模型，还有添加商品和查询商品的业务模型，比如下午9点添加商品占比40%，下午16点查询商品占比20%，那么就需要重新计算了

添加商品业务模型：
首先拿到9点这一小时的数据为10万，那么tps = 100000/3600*40% = 11.1/sec

查询商品业务模型：
首先拿到16点这一小时的数据为8万，那么tps = 80000/3600*20% = 4.44/sec

性能问题1：如果500tps那并发线程数应该是多少？

首先搞清楚一个概念就是：服务器的tps是有一个阈值的要达到500tps 用50个并发线程数和100并发线程数，或者200并发线程数都可以达到500tps，还有一个概念并发线程数和并发用户数不是同一个概念，并发线程数是jmeter里面的线程数，而并发用户数是需要通过tps来进行承载的，这个里面的并发用户数就是500tps

再延伸一点：如果需要达到500tps并发用户数，如果并发度为1%，那么在线用户应该就是500tps/1% = 50000的在线用户，这个并发度又是怎么计算的呢？
并发度计算：50000的在线用户，在1秒内发出来了500个接口请求，那么并发度等于500/50000=1%，这个就是并发度的计算公式

注册用户计算：可以取在线用户的10-100倍，也就是50万*500万 = 50万-500万的注册用户

500tps = 50个并发线程数/0.1秒
500tps = 100个并发线程数/0.2秒
500tps = 200个并发线程数/0.4秒
…
500tps = 1000个并发线程数/2秒

总结：用更多的并发线程数来做压测或者负载，不会让服务器的tps继续往上增加，只会增加响应时间，因为每台服务器的tps是有一个上限阈值的，到了这个阈值就不会再增加了。

性能问题2：你们之前支持多少个并发？

所以经常有面试官问你，你们之前支持多少并发，其实这个并发是指的并发用户数，而不是并发线程数，并发用户数是通过tps来承载的。

你上面说的500tps，你就可以理解为并发用户数就是500tps，最高支持500个并发，而jmeter里面的那个线程数指的是并发线程数，加大并发线程数只会让响应时间变大，而不会增加tps，并且jmeter里面线程数加到超过500，jmeter自身就会很卡。

2、tps上不去的原因

1）网络带宽：当你模拟大量用户发起请求的时候，单位时间内传递的数据包过大，超过了带宽的传输能力，造成网络资源竞争，间接的就导致了服务器接收的请求数达不到服务器的处理能力上限，tps值自然就不会上升。

2）连接池：连接池一般主要有两种，应用服务器连接池配置和数据库连接池配置，配置太小，连接数被占满了，新的连接只能等待，tps值也就自然不会再上升。

3）垃圾回收机制：JVM的垃圾回收GC都是基于算法的，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收频繁，那么对TPS就会有影响，因为垃圾回收本身占用一定的资源。

4）数据库配置：对数据库进行的读、写数据操作时，连接数、库表索引、读写分离、数据库主从方案等都有关系
5）通信连接机制：通信连接我们常见的有串行、并行、长连接、管道连接等
6）硬件资源：服务器硬件资源消耗过高，服务器处理不过来，tps也就上不去了

7）压力机：用jmeter做性能测试，一台机器并不能无上限的虚拟并发用户，想要高并发，可能机器根本虚拟不出预期的用户数，服务器tps自然也就不会上升。
8）压测脚本：我们都知道，性能测试，脚本是一方面，还要有性能场景设计，如果脚本+场景设计不合理，也不会达到预期的效果。
9）业务逻辑：如果被测系统业务耦合度非常高，一个功能相当于在测试整个系统了，这样的系统，tps也高不起来。
10）系统架构：现在比较常见的都是在服务器上会增加缓存机制，缓存的服务器配置、命中率、缓存穿透、缓存过期等等，都会影响性能结果。

tps如果上不去我的监控和分析思路：

1）首先我会去Linux服务器端通过iftop命令结合dstat命令去看看网络是否稳定，带宽够不够，发的请求有没有到服务器

2）然后看不断的加线程或者请求，用top命令看看load值，平均负载和CPU，内存是否有变化，如果变化不大有没有可能是Tomcat服务器的连接池太小导致，发送的请求被限制了，我会去看看Tomcat是不是用的bio，改为nio并行的io看看tps的变化大不大

3）如果没有以上原因我会接着去看是不是数据库连接池太小，然后接着会通过jmap -head pid和jstat -gcutil pid 1000、vmstat 1 10命令去看看是否有频繁的fullgc和中断，上下文切换，如果有频繁的垃圾回收也会导致tps抖动厉害上不去，包括是否有频繁的上下文切换，内核被消耗，因为频繁的io读取也会导致上下文切换过高，从而资源飙升，最终导致tps上不去，所以我会通过dump一下当前的线程的堆栈信息去看看有没有阻塞之类的来进行定位

4）包括会去看是不是压力机本身压力就不够，这种我会通过分布式去压测
5）如果这些都做好了，我会去看一下是不是我的压测脚本里面事务比较复杂，并且加了思考时间之类的。
6）当然有必要的话我也会通过Prometheus+grafana进行全局的监控，如果通过skywalking去监控每个节点所耗费的时间来具体定位分析

性能测试排查问题的基本思路：

首先性能的整体监控策略我会采用先全局监控，再定向监控
1）用jmeter本地压测的时候，如果是报错socket closed关闭等等，然后接口连接时间过长，先去看看是否是没有设置超时时间，修改JMeter.properties文件配置
httpclient4.idletimeout= 设置成自己觉得合理的时间，一般可设置成10-60s，然后还会去看看是不是Tomcat最大并发数设置的太小

2）如果是报address already in use错误，在jmeter里面我会把使用KeepAlive去掉勾选，如果还是没有用，我会去注册表里面修改本地最大端口65534

3）如果单接口的TPS在压测过程中有出现大幅度的抖动，初步定位有可能是服务器的堆内存空间设置过小，引发频繁的fullgc导致，这个我会通过jstat -gcutil 命令主要去看youngGC和fullGC的情况，如果再去调整xms和xmx等等参数

4）如果出现TPS暂停显示或者剧烈下降，会去看看堆栈的日志，看看会不会存在blocked阻塞，也会通过vmstat命令去查看
5）如果通过top或者dstat -tcmnd --util-disk命令去查看CPU和内存的时候，发现压力不大但是CPU一直处于高位，我会通过jdk自带的jprofiler工具去看看具体占用CPU最大调用的是哪个方法，看看是否有阻塞的情况

6）如果是数据库有慢sql的问题我会通过slow命令和explain分析工具去看看是否有慢sql，并且是否设置了索引等等
以上就是我之前定位性能问题的大概的思路。

首先性能的整体监控策略我会采用先全局监控，再定向监控

如果我们公司有promethues和grafana结合influxdb或者zabbix等性能监控工具的话，我会去做计数器的采集然后通过图形化界面展示然后去进行一个查看然后分析

但是如果没有图形化的监控工具，我会通过如下的命令去监控
用top和dstat ，jstat -gcutil 等等命令去监控CPU和内存情况
用jvisualVM工具去监控Java应用的GC情况，看看是否有fullgc等等

然后用iostat和iperf3去监控IO和网络带宽的情况，以上是对服务器端的性能监控手段

然后如果是报错socket closed关闭等等，然后接口连接时间过长，我会去看看是不是Tomcat最大并发数和数据库的线程池设置的太小，如果是数据库有慢sql的问题我会通过slow命令和explain分析工具去看看是否有慢sql，并且是否设置了索引等等。以上大概就是我的一个性能监控的分析思路

完整版！企业级性能测试实战，速通Jmeter性能测试到分布式集群压测教程

下面是我整理的2026年最全的软件测试工程师学习知识架构体系图