超细整理，性能测试如何做？怎么做？性能压力负载（汇总三）

前言

做性能测试的时候需要关注哪些性能指标，监控体系是怎样的，从哪些方面进行瓶颈分析，怎么调优？

1）关注的性能指标：
业务指标主要关注了：接口的平均响应时间、90%line、吞吐量tps（系统每秒处理事务数）、错误率
资源指标主要关注了： cpu、内存、磁盘、网络（i/o）
应用指标主要关注了：如空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时等。

前端指标主要关注了：如页面加载时间、网络时间（DNS、连接时间、传输时间等）
我们当时规定的tps必须要达到270/s以上，接口的平均响应时间要小于3秒，错误率为0%，CPU和内存的使用率是需要低于70%以下的

2）监控体系
操作系统：CPU（User、Sys、Wait、Idle）利用率、内存利用率（包括Swap）、磁盘I/O、网络I/O、内核参数等。
中间件：线程池、JDBC连接池、JVM（GC/FULL GC/堆大小）。
数据库：效率低下SQL、锁、缓存、会话、进程数等。
应用：方法耗时、同步与异步、缓冲、缓存。

3）瓶颈分析
操作系统资源消耗：CPU、Memory、Disk I/O、Network I/O。
中间件指标：线程池（Thread Pool）、数据库连接池（JDBC）、JVM（GC/FULL GC/堆大小）。

数据库指标：效率低下SQL、锁等待/死锁、缓存命中率、会话、进程等。
应用：方法耗时、算法、同步和异步、缓存、缓冲。

压力机：压力机资源消耗，一般情况下，压力机成为瓶颈的可能性非常低。PTS压力机有保护和调度机制不用单独关注。

4）调优
中间件调优：线程池、数据库连接池、JVM。
数据库调优：效率低下SQL、死锁和锁等待、缓存命中率，进程和会话参数。
应用调优：方法耗时、算法、同步和异步、缓存、缓冲。
系统资源：一般情况下，系统资源（例如CPU等）大部分是由应用和参数设置不合理导致的，并非系统资源不够。

TPS是怎么计算的？

我们当时是根据运维提供给我们的数据，然后按照2:8原则，也就是每天80%的业务量都是发生在20%的时间内。

比如说需要我每天的交易量需要达到50万笔，那么按2:8原则推算就是(50万*80%)/(8小时*20%*3600)=69.4笔/秒，取整为70笔/秒，然后加上有可能有业务扩容乘上一个冗余系数3，最终的TPS就是210/sec左右

简单场景TPS的计算方式：TPS的计算公式 ==》TPS=1/响应时间*并发数 ==》TPS=并发数/响应时间 125TPS = 100/0.8秒

性能测试-电商系统tps计算方法

怎么计算得出tps指标？

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

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

举个例子，比如我们xxx系统，从2025-9-8到2025-10-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

如上是通用的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性能测试

九、总结（尾部小惊喜）

人生最动人的风景，往往藏在最难攀爬的高处。当你觉得力竭时，请记住：每一次坚持都在雕刻更强大的自己。别问路有多远，只管迈步向前；别怕山有多高，向上攀登就是答案！

你体内沉睡着改变世界的力量！每个清晨都是改写命运的新机会，每次挫折都是精心包装的礼物。当全世界都在说"不可能"时，正是你证明"可能"的最好时机！