Jmeter性能压测4000并发

性能测试的底层逻辑

• 程序为什么会有性能问题

用户操作 客户端（web/app/小程序）触发网络请求，服务器处理大量网络请求代码运行需要大量服务器资源（CPU、内存、网络、磁盘等等）

资源不是无限，硬件配置不是随意变动。

大量请求带来资源消耗大于服务器资源，就出现性能问题（响应慢、报错、...）

• 性能测试的目标是什么?

通过模拟出大量用户使用的情况，分析程序的反应（响应时间、吞吐量、是否报错...）

• 如何模拟性能场景（这次目标）

要性能测试，先做接口分析

        压测目标场景涉及的接口

        性能之前先测接口

借住工具去发起大量请求-Jmeter

         一人一双手，无法模拟大量请求。

如何模拟多个用户操作的场景

• 借助工具 发起 海量的网络请求(jmeter、loadrunner、k6、Locust..)
• 线程(虚拟人)-操作系统底层去执行一个任务的最小单位
• 线程组配置:

                  线程数量: 申请多少线程来为你工作

                  Ramp-Up时间(秒):线程就绪的时间(多久时间让线程就绪)

                  循环次数:

                        输入数字: 线程执行的任务的次数

                        永远:一直干活不停，干完一次就下一次

                   调度器:持续时间-测试的时间长短

1.线程各干各的(单个线程的角度，干活的顺序就是你定义的先后顺序)
2.如果制定了循环次数: 线程执行完指定的次数后，线程结束
3.如果指定了持续时间: 时间一到，线程陆续停止干活

线程数量如何确定

考题1：每秒20个请求，持续至少30秒钟

方案1：20线程，持续30秒，循环次数：永久

结果：30秒左右--请求了800 每秒27.8

方案2：600线程，持续30秒，Ramp-Up:30秒，循环次数：1

结果：正确

• 样本数: 压测过程中jmeter发起的总请求数
• 响应时间: 系统在 指定的压力状态下，能否及时响应用户请求
• 吞吐量: 每秒处理的请求数量

方案3：20线程，持续30秒，循环次数：永久+ 定时器

相比较方案2：不需要频繁的创建线程和销毁线程，节约jmeter所在服务器的压力

工作中经常碰到场景1:领导(架构师)直接说 测一下系统能不能支撑 4000/s 请求

方案2思路: 总共:172,800,000 个线程、分为43,200秒（12小时）启动(不建议)

弊端: 每秒都会有 4000个线程被创建和销毁，极度消耗jmeter所在机器的CPU资源。(可能导致运行jmetgr的机器就卡住了)

方案3思路:4000个线程，每秒种发起一次请求，持续指定的时间。

弊端：一个电脑上运行大量的线程，可能导致电脑卡顿，从而达不到想要的并发压力

Jmeter分布式集群压测

通过 多台机器 同时执行 性能压测脚本，模拟更大的并发压力

1.多个独立环境，运行jmeter            

2.执行机 环境搭建与启动 

 3.控制机 修改配置文件重启jmeter

 远程启动 

 4000个线程 有2个服务器 每个服务器就运行2000个

学习可参考：jmeter分布式集群压测_jmeter集群压测-CSDN博客​​​​​​​