资深老鸟，性能测试-TPS上不去分析+电商系统TPS计算（详细）_接口tps

---

前言

1、性能测试-TPS上不去哪些原因导致的？

1）网络带宽

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

2）连接池

可用连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行），没有保持长连接，TCP 连接频繁中断

3）GC

如果堆内存分配的不合理，就会导致频繁的gc，gc会导致线程暂停。尤其是fullgc，会造成线程长时间暂停，代码故障，list 使用 contain 方法进行遍历去重，线程阻塞或者死锁

jvm 内存分配故障，fullgc 频繁，内存溢出

4）数据库配置

高并发情况下，如果请求数据需要写入数据库且需要写入多个表的时候，数据库的最大连接数不够，或者写入数据的SQL没有索引，或没有主从分离、读写分离，就会导致数据库事务处理过慢，还有数据库没加索引，db 缓存空间不足，也会影响到TPS。

5）硬件资源

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

6）压力机

单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，会影响TPS（这个时候就需要进行分布式压测来解决问题）

7）其他中间件

Nginx 负载均衡策略不当，压力分配不均
Redis 瓶颈。hash 未合并，缓存被击穿，单条命令耗时过长

8）硬件资源中CPU和内存

服务器资源不足，上下文切换过快，中断过高，swap 交换频繁
压力大的时候tps频繁抖动，导致总tps上不去。查看是否有fullgc（tail -f gc_mSrv1.log | grep full）

pacing设置太小也会导致tps上不去，对抖动大的交易多增加点用户即可。
tps抖动，单压抖动大的交易，发现很平稳，这时怀疑是不是压力太大导致，所以发容量的时候把压力最大的那只交易分到其他压力机，然后发现tps不抖动了。

注意：多台压力机只影响tps抖动，不会影响服务器的cpu。看响应时间有没有超时，看用户数够不够。

2、性能测试-电商系统TPS计算方法

怎么计算得出tps指标？

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

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

我举个例子，比如我们yshop系统，从2023-4-8到2023-5-8，最高的一天调用接口数量最高为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
1
2
3
4
5
6
7
8

如上是通用的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自身就会很卡。

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

努力奋斗，不断超越自我，让梦想的火花照亮前行的路途，每一次的坚持都是向成功进发的关键一步，终将绽放出绚丽的人生篇章。

披荆斩棘，砥砺前行，坚韧不拔的奋斗之路上，每一次的努力都在铺就通往成功的阶梯，让心中的梦想驱使着你勇往直前，终将获得辉煌的成就。

在逆境中磨砺意志，在迷茫中寻找方向，坚持不懈地追逐梦想，勇敢面对挑战，奋斗的每一步都是通往成功的征程，绽放出生命的华丽光芒。