负载测试中Crash Point与Degradation的定义及差异咨询

作为常年泡在性能测试领域的老鸟，我来给你掰扯清楚这俩核心概念，以及它们之间的关键差异：

Crash Point（崩溃点） #

这就是负载测试里的终极红线——当系统承受的负载突破某个临界点时，直接彻底“罢工”了。具体表现可能是：

• 服务直接宕机，完全无法处理任何请求
• 数据库连接池耗尽、线程池打满，导致所有请求超时或报错
• 应用抛出致命异常，进程直接终止

举个实际例子：你压测一个在线票务系统，当并发用户冲到8000时，服务器突然失去响应，监控面板显示CPU占用100%且内存溢出，这时候的8000并发量就是这个系统的Crash Point。

Degradation（性能降级） #

这个阶段系统还没到崩溃的地步，但已经开始“力不从心”，性能指标开始偏离预期标准。典型表现包括：

• 响应时间大幅增加：原本200ms能返回的接口，现在延迟到1s以上
• 错误率上升：比如有2%-5%的请求返回5xx错误，但大部分请求仍能正常处理
• 非核心功能失效：比如系统自动关闭了图片压缩、推荐算法这类非必需功能，优先保证核心的购票流程

简单说，就是系统还在干活，但已经“喘粗气”了，用户体验开始打折扣，但核心功能还能凑合运行。

二者的核心差异 #

• 触发时机不同：Degradation是性能下滑的起始点，会在Crash Point之前出现——系统先慢慢“累垮”，才会彻底崩溃
• 系统状态不同：Crash Point阶段系统完全丧失服务能力；Degradation阶段系统仍可提供服务，只是性能不达标
• 恢复成本不同：到达Crash Point后，通常需要人工重启服务、排查修复故障才能恢复；而Degradation阶段只要降低负载（比如减少并发用户），系统就能快速回到正常性能水平
• 影响范围不同：Crash Point是全局性故障，所有用户都无法使用服务；Degradation可能只是部分用户体验变差，或者非核心功能受影响，核心流程仍能运行

内容的提问来源于stack exchange，提问作者Divya Master