1. 项目概述先搞清楚我们到底在聊什么聊性能测试、负载测试、压力测试之前得先承认一件事这三个词在日常沟通里被混用得相当厉害。我见过不止一次面试候选人把“压测”挂在嘴边结果问下去发现他说的其实是“用JMeter跑了一轮普通性能测试”也见过测试群里有人抛出一张LoadRunner的报告截图标题写着“压力测试结果”点开一看线程数稳定在50根本没有摸到系统的任何上限。这个现象不奇怪。性能测试本身是一个大类负载测试和压力测试只是它下面的两个分支方向。很多人被市面上各种培训资料绕晕了是因为大部分文章只给定义不加场景更没有告诉你“同一个工具、同一套接口怎么分别完成这三种测试”。所以这篇内容我打算换个角度写不背书上的定义而是从目标、从数据、从具体操作上去拆把三者的区别聊透顺便把JMeter、r23、gpu-burn这些热词背后的实操逻辑也串进来。这套内容适合谁来看三类人第一类是刚入行或者即将面试的测试工程师需要把概念彻底理清第二类是后端或者运维的同学想搞明白压测报告里那些指标到底代表什么第三类是准备给电脑做散热验证、给服务器做稳定性考核的硬件爱好者你需要知道自己到底该跑哪一类压力测试。不管你是哪一类看完之后至少能回答清楚一个问题我的场景到底应该做性能测试、负载测试还是压力测试。2. 三者之间的本质区别目标、方法和判断标准完全不同2.1 性能测试到底在测什么性能测试是最容易理解的一类它的核心目的是验证系统在预期负载下各项指标是否满足预设要求。注意关键词——“预期负载”。也就是说你的系统在设计的时候业务方告诉你峰值并发是1000那么性能测试就是围绕这1000来做验证系统能不能扛住响应时间多少CPU、内存还有多少余量。我用一个贴近生活的例子来类比。你买一台新车厂家说这车最高时速能跑180百公里加速8秒那你在高速上开到120验证一下油耗、噪音、稳定性这就是性能测试。它不追求把车逼到极限只关心在正常甚至偏高的使用场景下车子的表现是不是符合宣传。放到软件系统上性能测试关心的核心指标通常包括TPS每秒事务数或者QPS每秒查询数衡量系统处理能力响应时间包括平均响应时间、90%响应时间、99%响应时间资源使用率包括CPU、内存、磁盘IO、网络带宽。性能测试的脚本设计相对简单通常按照生产环境的典型业务比例模拟一个比较平稳的负载模型持续运行一段时间。它的产出是一份“达标情况说明”当前系统在预期负载下各项指标是达标还是不达标如果不达标离目标差多少瓶颈可能在哪里。2.2 负载测试是慢慢加砝码找规律负载测试比性能测试更进一层它的核心目的是找到系统的最优负载区间和出现性能拐点的位置。怎么找从低到高阶梯式地增加并发用户数观察系统各项指标的变化轨迹。还拿汽车来说。负载测试就是开着这辆车从时速60开始每过一段时间加20观察发动机转速、油耗、温度的变化。你会看到一个规律转速上升车速提升但是到某个临界点之后车速再提上去油耗会急剧增加甚至发动机出现明显的吃力震动。这个临界点对应的状态就是你“最优负载”和“过载”的分界线。放到系统上负载测试通常这样设计预设一组递增的并发数比如100、200、400、800、1200每个并发档位维持固定时间比如10分钟每个档位都收集TPS、响应时间、错误率、资源使用率最后把数据连成曲线找到“TPS不再线性增长”甚至“TPS反而下降”的那一点。这个拐点非常关键。它是容量评估的核心依据告诉你系统当前最大能扛多少并发也告诉你在线程数继续增加的时候系统是直接崩溃还是表现为响应时间骤增。这两种表现对应完全不同的架构问题。2.3 压力测试是奔着崩溃去的压力测试在很多人眼里和负载测试是一回事这其实是最常见的误解。负载测试关注的是“找到那条线”压力测试关注的是“越过这条线之后会发生什么”。换句话说压力测试是持续增加负载让系统超负荷运行甚至直接被打垮然后观察系统的失败模式、恢复能力、是否雪崩。还是那辆车。负载测试开到180发现极限了收工。压力测试则是开到180之后再继续闷油门让发动机超转速运转看它是拉缸、爆缸还是自动断油保护。做压力测试的人心里很清楚这个过程是有可能损坏系统的所以在软件领域压力测试通常在测试环境或者专门搭的压测集群上做绝不会拿生产环境开玩笑。压力测试的核心观察点包括系统是优雅降级还是直接宕机报错的方式是什么是超时、拒绝连接还是返回5xx资源打满之后系统恢复需要多久有没有缓存击穿、线程池耗尽、数据库连接池泄露等连锁问题。压力测试的价值在于为系统设定一个安全边界同时验证防护机制是否有效。比如限流、熔断、降级这些手段平时不压到极限根本看不出好不好用。压力测试就是把它们逼出来。2.4 一张表说透边界对比维度性能测试负载测试压力测试核心目标验证预期负载下是否达标找到最优负载和容量拐点验证超负荷下的行为与恢复能力负载模型稳定在预期并发阶梯式递增寻找规律持续高压甚至超出极限执行结果达标/不达标容量曲线、拐点数据崩溃模式、异常表现、恢复时间风险级别低中高可能导致系统不可用典型产出指标报告判定是否可上线容量评估指导扩缩容稳定性报告验证防护机制这张表每次讲公开课我都会放出来因为它把最抽象的部分压缩成了一目了然的对比。简单记法是性能测试是“证明行”负载测试是“测出极限在哪”压力测试是“看看过了极限怎么死”。3. 手把手落地用JMeter依次完成三类测试3.1 JMeter跑负载测试的完整步骤热词里反复出现“jmeter性能测试步骤”说明用JMeter做测试是绝大多数团队的默认选择。JMeter本身是开源免费的生态成熟插件丰富掌握它是测试工程师的基本功。下面我按最典型的场景来走一遍对一套登录接口先做性能测试再做负载测试。第一步创建测试计划。打开JMeter后默认会有一个空的测试计划右键添加线程组。线程组里有三个关键参数线程数、Ramp-Up时间、循环次数。这里分享一个不那么显眼但很重要的细节Ramp-Up时间建议设置成线程数的四分之一到二分之一也就是100个线程用25到50秒慢慢拉起来。这样更贴近真实用户逐步进入系统的场景也避免一瞬间的并发冲击把结果搞得太极端。第二步添加HTTP请求。在线程组下添加Sampler选择HTTP请求填写协议、服务器地址、端口、路径。如果接口是HTTPS的记得在请求里加上HTTP请求头管理器把Content-Type设置成application/json。参数化做不做对于一次基础的性能测试可以先写死但要模拟真实场景最好用CSV数据集配置从文件里读取账号密码。第三步添加监听器。聚合报告是最常用的里面能看到样本数、平均响应时间、中位数、90%和99%行、吞吐量、错误率。再加一个查看结果树方便排查错误请求的具体响应内容但注意压测时不要开着它跑全程因为查看结果树要保存每个请求的完整数据极其消耗本地内存往往压测没结束JMeter自己先卡死了。正确做法是调试脚本时开着结果树正式压测时关掉。第四步跑一轮性能测试。线程数100、持续运行5分钟观察聚合报告。如果平均响应时间在预期范围内错误率低于0.1%资源使用率不超过70%性能测试就算通过。第五步改造脚本做负载测试。把线程数改成变量比如用${__P(threads,100)}这种方式从命令行传入。然后依次执行300并发跑10分钟600并发跑10分钟900并发跑10分钟1200并发跑10分钟。每轮记录TPS和响应时间。最后把数据整理成表格你会看到类似这样的规律并发数TPS平均响应时间(ms)错误率1001801200%3004801800%6007802600%9008504600.2%12007609803.5%注意第三行到第四行的变化TPS从780涨到850涨幅明显放缓响应时间却几乎翻倍。这说明拐点正在出现。第四行到第五行TPS直接掉头向下错误率开始抬头说明系统已经进入过载状态。这个数据组合就是负载测试最有价值的产出。3.2 把压力测试跑起来负载测试跑完之后压力测试脚本几乎不用重写只需要调整线程组配置。核心区别在于压力测试要让所有线程瞬间进入系统不给系统预留适应时间并且持续施压。操作上把Ramp-Up时间设成0让1000个线程同时冲击循环次数设成Forever再通过调度器配置持续运行时间比如10分钟。如果条件允许还可以配合JMeter的Stepping Thread Group插件让线程数持续攀升每30秒增加100个并发直到系统彻底崩溃。压测过程中你需要同时监控服务端的指标。推荐用两种方式如果是K8s环境直接看Prometheus和Grafana大盘如果是裸机部署用命令行的top、vmstat、free、iostat就够用。这里强调一个细节监控数据的时间戳要和JMeter的压测时间对齐不然事后排查的时候你根本不知道哪个资源指标对应哪一波并发。最简单的办法是压测开始前先在服务器上执行date命令记录一个基准时间同时把JMeter的测试计划名称写上当前时间点两边一比对就很清楚了。压力测试做到什么程度可以收手我的标准是系统出现了明显的保护性行为比如限流生效、熔断打开、请求被拒绝并且你能清晰描述当前并发数下的系统状态。不要真的把整个集群打物理宕机那对测试环境来说也是负担很多云厂商的压测资源是按量计费的一直打到机器死机重启成本也不低。3.3 JMeter实操中容易踩的坑先说一个最常见的坑JMeter线程数设置成多少不代表系统就有多少并发。线程发出的请求如果都是短连接可能实际同时只有几十个请求在服务端处理。要模拟出真实并发需要在每个线程里用循环控制器或者同步定时器Synchronizing Timer来保证足够多的请求同时到达。同步定时器的作用类似一个栅栏等集合了指定数量的请求后一起放出是压测里实现“真并发”的关键组件。第二个坑是JMeter本身的性能瓶颈。JMeter是Java应用默认JVM堆内存很小压测线程多起来之后客户端自己可能先OOM。在bin目录下的jmeter.bat或者jmeter.sh里找到HEAP-Xms1g -Xmx1g -XX:MaxMetaspaceSize256m这行配置建议修改成-Xms2g -Xmx4g。注意JMeter的实例和施压目标机器最好分机部署不要让JMeter压力客户端和被测服务抢同一台机器的CPU和内存否则结果会严重失真。第三个坑是局域网环境下的压测不准。无线网络下跑压测会造成大量随机延迟必须使用有线连接。如果压测目标在云端本地JMeter和云端之间的网络带宽、延迟也要纳入考量尤其是在压测量级比较大的时候可能瓶颈根本不在服务端而在你本地到云端的这条链路上。这种情况下最好用云压测平台或者在被测环境的同VPC内部署一个施压机。你可以自己写脚本做副本来避免上榜工具不存在的就是实际操作层面的经验。第四个经验相关性分析。压测报告里如果CPU使用率接近100%但TPS很低先别忙着怀疑代码性能先看是不是单核瓶颈。Java应用如果没有充分使用多核单核打满而其他核空闲的情况我见过很多次。排查方式是在压测期间执行top然后按1查看每个CPU核心的使用率如果其中一个核接近100%而其他核只有20%基本可以断定是应用启动参数或者代码里某条公共链路没有做好并发控制比如并发锁、单线程池等。4. 延伸场景CPU和GPU压力测试怎么做4.1 CPU压力测试r23是基准也是烤机热词里的“r23压力测试”指的是Cinebench R23。这个软件原本是做CPU渲染性能基准测试的但因为它的渲染负载极其吃CPU能把CPU顶到全核满载所以在DIY圈被当成了CPU稳定性测试工具也就是“烤机”。怎么跑下载安装Cinebench R23之后界面很简单左边是Single Core测试右边是Multi Core测试还有一个10分钟的Multi Core循环测试按钮。做CPU压力测试推荐跑10分钟Multi Core。10分钟的意义在于让CPU持续处于高负载状态观察散热能不能压住。如果散热不行CPU会撞到温度墙然后降频导致跑分明显下降。重点看三个数据跑分分数、CPU封装温度、主频波动。跑分用于同型号CPU之间的横向对比如果分数明显低于同型号的平均水平说明散热或供电有问题。温度方面主流的Intel和AMD处理器在满载时90度以内都算正常超过95度就得警惕。主频波动怎么看用HWiNFO64在后台记录CPU频率曲线如果出现断崖式下跌大概率是撞温度墙或者功耗墙。我自己的习惯是新装机或者更换散热器之后先跑一轮R23再跑一轮AIDA64的系统稳定性测试里的FPU烤机。FPU烤机的负载比R23更极端是压榨AVX指令集的发热量极大。如果FPU烤机能稳定跑15分钟不蓝屏、不重启、不降频这台机器的CPU稳定性基本可以过关。这里有个容易忽略的细节CPU压力测试之前先更新主板BIOS到官方最新版本因为很多CPU的微码调度问题、温度读数不准问题都是靠BIOS更新修复的。如果机器还是老BIOS压测出来的温度和频率数据可能没有参考价值。4.2 GPU压力测试gpu-burn的正确打开方式gpu-burn是一个在Linux下运行的GPU压力测试工具专门用来烤NVIDIA显卡。它底层调用CUDA会让GPU跑满计算任务持续输出高负载用来验证显卡的稳定性、散热和供电是否可靠。这个工具在深度学习和HPC集群的验收环节里出场率极高。用法很简单。先确认机器上安装了NVIDIA驱动和CUDA工具包然后执行git clone https://github.com/wilicc/gpu-burn cd gpu-burn make ./gpu_burn 120最后面的120单位是秒意思是让GPU持续满载120秒。跑的过程里在另一个终端用nvidia-smi监控GPU使用率、显存占用、温度和功耗。正常情况GPU使用率会稳定在95%以上温度会爬升到一个平台期然后稳定住功耗也会维持在一个恒定范围。如果中途出现驱动崩溃、机器重启、或者nvidia-smi里显示Ecc Error或者其他异常说明这张卡有硬件层面的隐患。gpu-burn更进阶的用法是通过环境变量控制负载类型比如./gpu_burn -d 60 -m 1024 180这里的-d是显存占用MB数-m是矩阵大小。调整这两个参数可以模拟不同的负载场景。比如你主要是跑大模型推理的就把显存占用拉高验证显存颗粒的稳定性如果主要是跑科学计算的就把矩阵设置得大一些重点压榨计算单元。需要注意的一个点是gpu-burn跑起来之后机器可能会非常“卡”尤其是通过SSH连接的会话因为GPU满载会导致图形界面响应迟缓。我的经验是压测期间不要依赖图形界面操作所有命令都提前写好或者直接用Tmux会话挂跑不然一断连进程就跟着断了。4.3 PC端压测和服务器压测目标逻辑完全不同CPU和GPU压测在PC端的意义是验证散热和稳定性但在服务器端压力测试的意义要宽泛得多。比如GPU服务器除了gpu-burn之外还得配合跑一类真实的模型训练任务观察多卡之间通信是否正常。只跑gpu-burn看温度是测不出NVLink和PCIe通信毛病的。同理服务器CPU压测很少用R23而更倾向于用stress-ng这类工具因为它可以精确控制负载类型比如纯整数运算、纯浮点运算、内存分配、文件IO、上下文切换等。原因是服务器端做压力测试目标往往是验证某个特定组件在极限负载下的表现而不是单纯看一个综合跑分。这种PC端与服务器端的差异其实也是前面三类性能测试概念的外延。PC端跑R23、gpu-burn对应的是“单机硬件压力测试”服务端用JMeter、LoadRunner做压力测试对应的是“业务系统压力测试”。两者表面操作差别很大底层逻辑一致持续加载到超出常规范围观察系统在极限状态下的表现找到稳定边界。5. 实际项目里的协作打法性能、负载、压力交替进行把三类测试放在一个真实项目里去执行最常见的错误是只做其中一种。我在负责一个电商交易系统压测项目时经历过一次教训性能测试全绿直接上线结果大促当天出现响应时间偏高、部分订单丢失。事后复盘发现我们只验证了“预期负载下指标达标”却没有做负载测试系统容量拐点远低于预期而大促的流量直接越过了那个拐点。那次之后我给团队定了一套流程第一个阶段摸底性能测试。用预估的日常峰值并发的50%先跑一轮确认基本链路通畅脚本数据准备到位。这一步的目的是跑通流程发现明显的功能性问题比如参数化数据不够、断言写错、接口鉴权过期等。很多JMeter脚本问题都在这个阶段暴露。第二个阶段阶梯式负载测试。从预估峰值的30%开始每级增加30%左右并发每级稳定跑15到20分钟。这轮结束后能拿到一条完整的容量曲线找到系统的拐点。根据拐点数据团队决策是否需要做扩容、限流配置调优或者代码优化。这里分享一个数据参考线上系统的容量规划通常按预估峰值的2倍来预留资源也就是说如果日常峰值是500并发负载测试至少要跑到1000并发还能保持稳定才能给业务方留出安全余量。第三个阶段压力测试。把负载拉高到拐点之上的1.5到2倍持续10分钟以上甚至直接模拟突发流量风暴。这一轮重点验证限流、熔断、降级策略是否生效。如果压测过程中发现系统直接雪崩那反而是好事因为在测试环境暴露问题比在生产环境被动挨打成本低得多。结合热词里的“aijmeter性能测试”现在很多团队也会把AI能力用来辅助分析压测数据比如自动识别TPS拐点和异常曲线模式但核心的压测配置和数据分析逻辑仍然没有变。第四个阶段稳定性测试。在峰值并发的80%负载下持续运行12到24小时验证是否有内存泄漏、连接池耗尽、磁盘占满等慢性问题。这部分很多时候被归到性能测试大类里但它的目标不是验证单项指标而是验证“扛得住”的持续性。JVM内存监控、慢SQL日志、GC日志在这个阶段都要打开收集完整数据后再逐步降低负载观察系统是否能平稳回落。这套流程看起来繁重但实际执行下来前三个阶段通常加起来只需要两到三天时间。真正耗时的是第四阶段的稳定性长期观测不过它往往可以和测试环境的其他工作并行进行不会占用太多额外时间。6. 常见问题排查与避坑速查问题现象可能原因排查思路与解决方法JMeter压测时TPS上不去服务端CPU却不高施压机性能不足、网络带宽受限、同步定时器没加先看施压机的CPU和内存换有线网络检查JMeter日志是否出现OOM压测后期错误率突然上升连接池耗尽、数据库连接泄露、超时设置不合理查看Tomcat/数据库连接池的活跃连接数检查超时配置和慢查询响应时间正常但TPS偏低接口逻辑串行化、锁竞争、单线程瓶颈用Arthas或jstack抓线程栈分析阻塞点查看单核CPU是否打满压测后系统重启才恢复文件句柄耗尽、内存泄漏、线程栈溢出压测期间持续监控文件句柄数和内存曲线确认是否有缓慢增长gpu-burn跑几分钟出现驱动崩溃GPU供电不足、散热不良、显存硬件隐患检查电源功率更新驱动用nvidia-smi查看温度与功耗单独跑显存测试确认R23跑分远低于同型号平均散热问题撞温度墙、BIOS功耗墙设置、内存跑在默认频率用HWiNFO看温度和主频曲线检查BIOS里XMP是否开启CPU供电是否稳定这里面再补两个独家经验。第一个是关于压测数据准确性的JMeter的聚合报告里吞吐量和响应时间默认是累计平均如果压测过程中有部分请求超时平均值会被拉得很高。这时候一定要看90%和99%行它们反映的是绝大多数用户的体验比平均值更有价值。而且压测结束之后最好把异常请求单独筛选出来看搞清楚具体是哪一类接口在报错而不是笼统地看错误率。第二个是关于压测计划里的时间窗口给压测设置的时间不能太短低于5分钟的结果往往不具备参考价值因为JVM的JIT编译预热、连接池初始化、缓存预加载这些都需要时间系统刚启动时的表现不能代表稳定运行时的表现。在性能测试和压力测试的实操里还有一个很容易被忽略的点压测数据准备。登录态的Token过期、观察订单数据的库存不足、唯一约束冲突这些问题都会导致压测脚本跑到一半批量报错。我的做法是每次压测前都先跑50个并发、持续30秒的冒烟验证确认数据没问题再开大并发。这一步多花两分钟能避免整轮压测作废。热词里还有一个“电脑如何cpu压力测试”这里也一并说掉。Windows用户最简单的做法是下载Cinebench R23跑10分钟Multi Core循环再配合AIDA64的FPU烤机。macOS用户可以用命令行工具yes /dev/null 多开几个进程把CPU核心占满然后观察CPU温度和风扇转速。跑之前先用Macs Fan Control或者iStat Menus把温度监控打开不然盲烤摸情况遇到温度过高的机器可能会造成硬件损伤风险。最后聊一个新趋势。热词里有“aijmeter性能测试”我理解这说的是用AI能力辅助压测数据分析和脚本生成。目前实测下来AI辅助生成JMeter脚本已经能做到比较高的可用率特别是针对常见协议的接口比如HTTP、JDBC描述清楚业务场景之后生成的脚本一般改改就能跑。但对于压测数据分析AI更多是辅助工具它能帮你快速发现数据曲线里的异常点但最终判断仍然需要你自己结合业务背景做决策。这一点要清醒工具再智能也替代不了对系统本身的了解。