一、压测就是假装很多人同时来访问

【实测负载】的做法很直接：用一个工具按你设定的并发，反复打同一个地址。

四个常用工具在同样条件下（4 核 8G，压同一个接口）的对比：

• k6：CPU 45%、内存 380 MB、每秒 4800 请求、平均响应 208 ms。
• Gatling：CPU 52%、内存 620 MB、每秒 4650、平均 215 ms。
• JMeter：CPU 85%、内存 2.1 GB、每秒 4200、平均 238 ms。
• Locust：CPU 78%、内存 1.2 GB、每秒 3900、平均 256 ms。

四个工具差别不在【能不能压】，而在【压同样的量自己要吃多少资源】。 k6 是 Go 写的、Gatling 跑在 JVM 上，这两类引擎天生比【一用户一线程】的省。

这笔账往下推一层更明显——单个节点能模拟多少并发用户： k6 在 5 万以上，Gatling 3 万以上， Artillery 5000~20000，Locust 1 万以上（可分布式），JMeter 5000~10000。

差着一个数量级，而这一层直接决定了你到底是压测别人，还是在压测自己。

二、该看哪七个数字

压测不是压出一个【最大数字】就完事。要盯的是这七项：

• 响应时间（p95／p99）——平均会骗人，尾部才是真实体验。
• 吞吐量（每秒请求）——能扛多少。
• 错误率——开始出错的第一个信号。
• 并发数——同时在线多少人。
• CPU 与内存占用——瓶颈在哪一侧。
• 饱和度——排队排到什么程度。
• 曲线拐点——响应变陡的那一点，才是容量上限。

最后一项是重点。 真正该记住的数字不是最大值，而是【开始变坏的那个点】。 超过拐点以后再加压力，吞吐不再涨、响应直线上升—— 那之后加的所有压力，最后都变成了队列里的等待。

至于为什么盯 p95 和 p99 而不是平均值： 1% 的请求慢了 10 秒、99% 都很快，平均值依然很好看， 但用户的糟糕感受全在那 1% 里。

三、别把这三个混了

名字很像，测的东西完全不同：

• 负载测试——压在预期峰值，看能不能稳住。这是上线前做的。
• 压力测试——一直加压到崩，看崩在哪、怎么崩。这是找上限做的。
• 浸泡测试——中等压力跑几小时，专门找内存泄漏。这是找慢病做的。

三者不是强度上的差别，而是问的问题不一样。 第一种问【够不够】，第二种问【极限在哪】，第三种问【会不会越跑越差】。 尤其是第三种，只有时间能回答——内存泄漏不会在十分钟内暴露。

四、两条现实账

第一条是内存账，这是最容易算错的地方。 JMeter 是【一个虚拟用户一条线程】，差不多每个用户吃 1 MB 内存： 想压 1 万个用户，就得准备 10 GB 内存。 同样场景下 k6 自己只占 380 MB—— 这就是为什么它敢往 CI 流水线里塞，而 JMeter 塞进去会拖死构建机。

第二条是停机账，用来给压测的收益定个价：

• 大型企业每分钟停机成本约 23750 美元。
• 折成每小时是 1425000 美元。
• 41% 的企业每小时损失超过 100 万美元。

把这两条放一起，压测的性价比就很清楚了： 它花的是几个小时的人力，赌的是一次每小时百万美元级的故障。

最后一条行业现状：68% 的组织已经在质量工程里用生成式 AI， 但真正做到企业级规模的只有 15%。工具普及了，方法没跟上。

五、动手 Demo：压一台服务器，看它先在哪一步塌

两条账可以直接算：一台测试机要多少内存，一次停机值多少钱：

# JMeter：一个虚拟用户约 1 MB 内存
print("  JMeter 每虚拟用户约 1 MB：压 1 万用户要 %.0f GB 内存" % (10000 * 1 / 1024))
print("  停机每分钟 23750 美元 = 每小时 %.0f 美元" % (23750 * 60))

实跑输出：

--------------------------------------------------------------------
压一台服务器，看它先在哪一步塌
--------------------------------------------------------------------
  教材说的【实测负载】，就是用工具假装很多人同时来访问。
  四个常用工具在同样条件下的表现，有个公开的对比（4 核 8G，压同一个接口）：

  工具        CPU 占用     内存       每秒请求     平均响应
  ----------------------------------------------------------
  k6          45%          380 MB     4800         208 ms
  Gatling     52%          620 MB     4650         215 ms
  JMeter      85%          2.1 GB     4200         238 ms
  Locust      78%          1.2 GB     3900         256 ms
  ----------------------------------------------------------
  四个工具差别不在【能不能压】，而在【压同样的量自己要吃多少资源】。
  k6 是 Go 写的、Gatling 跑在 JVM 上，这两类引擎天生比【一用户一线程】的省。
  往下推一层，单个节点能模拟多少并发用户，差得更多：

  工具          单节点并发上限           适合谁
  ----------------------------------------------------------------------
  k6            50000 以上               有 JavaScript 团队的 CI 流水线
  Gatling       30000 以上               Java／Kotlin 团队
  Artillery     5000~20000               要 YAML 写测试定义的团队
  Locust        10000 以上（分布式）     Python 团队
  JMeter        5000~10000               要测数据库、SOAP 的老系统
  ----------------------------------------------------------------------
  内存这笔账最容易算错。JMeter 是【一个虚拟用户一条线程】，
  差不多每个用户吃 1 MB 内存：想压 1 万个用户，就得准备 10 GB 内存。
  同样场景下 k6 自己只占 380 MB——这就是为什么它敢往 CI 里塞。

  压测的收益，可以用停机成本来对照：

  场景                                       成本
  --------------------------------------------------------
  大型企业每分钟停机                         23750 美元
  折成每小时                                 1425000 美元
  一小时损失 100 万~500 万美元以上的企业     41%
  --------------------------------------------------------
  压测不是压出一个【最大数字】就完事，关键看七个数：

  看什么                   为什么看它
  --------------------------------------------------------
  响应时间（p95／p99）     平均会骗人，尾部才是真实体验
  吞吐量（每秒请求）       能扛多少
  错误率                   开始出错的第一个信号
  并发数                   同时在线多少人
  CPU 与内存占用           瓶颈在哪一侧
  饱和度                   排队排到什么程度
  曲线拐点                 响应变陡的那一点，才是容量上限
  最后一行是重点：真正该记住的数字不是最大值，而是【开始变坏的那个点】。
  超过拐点以后再加压力，吞吐不再涨、响应直线上升——那之后的全是等待。

  三件事别混：

  测什么       怎么测
  ----------------------------------------------
  负载测试     压在预期峰值，看能不能稳住
  压力测试     一直加压到崩，看崩在哪、怎么崩
  浸泡测试     中等压力跑几小时，专门找内存泄漏
  ----------------------------------------------
  顺带一个行业现状：68% 的组织已经在质量工程里用生成式 AI，
  但真正做到企业级规模的只有 15%。工具普及，方法没跟上。

10 GB 这个数字就是【压测机比被测机还贵】的来源。 很多团队第一次压测压不出结果，不是服务不行， 是压测机自己先满了。 所以选工具的第一条不是看功能，是看它自己吃多少—— 这一点和选监控工具是一样的道理。

30 秒实验

1. 按 F12 打开 Network 面板，刷新一个页面，看最慢的那个请求用了多久——那通常就是拐点的来源。
2. 登录你用的云平台，找【监控】页面，看有没有 CPU、内存的曲线图和告警设置。
3. 想一下你的网站一天里最忙是几点，那个时刻的访问量就是该拿去压的【预期峰值】。

常见误区

1. 错误：压测就是测出最大并发数。——纠正：真正要看的是曲线拐点；超过它以后再加压力，吞吐不再涨、响应直线上升，那一点才是有意义的容量。
2. 错误：看平均响应时间就够了。——纠正：平均会骗人；1% 的请求慢 10 秒、99% 都很快，平均值依然好看，但用户感受全在那 1% 里，所以要盯 p95 和 p99。
3. 错误：压测工具用什么都一样。——纠正：差别在工具自身的开销；压 1 万个虚拟用户，JMeter 要 10 GB 内存，k6 只要 380 MB，这直接决定你能不能把它放进 CI。

• ☐ 下一节（8-13 虚拟服务器的性能评估：标准值）

相关笔记

• 虚拟服务器的性能评估 —— 下一节讲买之前怎么判断它值不值
• 选择Web服务器服务套餐 —— 套餐里那些数字该怎么读
• 不可停止运行的系统2 —— 停机成本那个话题的另一面
• 增加负载的攻击类型 —— 压力大到一定程度就是攻击
• 负载的分散 —— 压不住的时候往哪儿分
• 🕸️ Web技术原理 · 索引