负载测试：在大促和旺季之前对网店与应用做压力测试

双日购物节、发薪日促销，或与大网红合作的直播：网店最期待的时刻，也正是系统最常崩溃的时刻。访客蜂拥而至，结账页面无休止地转圈，支付失败，几分钟内顾客就转向了竞争对手。广告费已经花出去，库存已经备好，团队正在加班，但销售却被一个应付不了的系统拖住了。

这类故障几乎总能在发生之前预见。负载测试是一种受控的演练，模拟许多用户同时访问您的系统，这样系统的薄弱点会在测试日而不是促销日暴露。许多企业以为这种测试只是大公司的事。实际上，依赖少数几个销售高峰日的中型企业受益最大。

本文介绍什么是负载测试、它的类型、测量什么、如何设计真实的场景、如何解读结果，以及成本、安全和通常影响最大的修复措施等实际问题。您不必是工程师也能理解其中的逻辑，而作为企业主，您可以要求技术团队或供应商提供清晰的结果。

摘要

• 负载测试模拟大量用户，在真实用户发现之前找到容量极限和故障点
• 测量高百分位的响应时间、错误率和资源使用，而不仅仅是平均值
• 根据真实行为设计场景：浏览商品、搜索、购物车、结账和支付，用户数量根据历史数据和活动计划估算
• 最常见的瓶颈出现在数据库、支付网关等第三方，以及无法扩展的组件
• 在类似生产的环境中测试，远在高峰之前，并留出修复和重复测试的时间

为什么系统在繁忙时崩溃

一个在一百名用户时运行流畅的系统，在五千名用户时不一定流畅。负载与性能之间的关系不是线性的。负载低时，增加用户只会略微增加响应时间。越过某个阈值后，队列堆积，响应时间急剧上升，错误开始出现。这个阈值由最薄弱的组件决定，而不是整个系统的平均水平。

一些经典原因：数据库查询在数据量少时感觉很快，但许多人同时访问时变慢；会话或连接耗尽；进程相互锁定；第三方服务限制请求数量；沉重的图片和脚本耗尽带宽；以及从未根据真实负载调整的服务器配置。这些症状与业务应用与数据库性能变慢中讨论的相关。

此外，促销期间的流量激增不同于逐步增长。流量在几分钟内飙升，用户行为高度一致（所有人都涌向同一个促销商品），而每位用户都在执行加入购物车和付款等重操作。正是这种组合把系统测试到极限。

值得了解的测试类型

“负载测试”一词常被用于目标不同的几种测试。

负载测试

模拟高峰日预期的用户数量，确认系统仍能达到性能目标。问题是：系统能否承受我们预期的负载？

压力测试

将负载提高到远超估计，直到系统失效，以了解其极限和失效方式。问题是：系统在什么数字下崩溃，又是如何崩溃的，是干净地停止还是扩散破坏？

突发测试

像促销链接被分享时那样突然提高负载，然后降低。问题是：系统能否迅速响应突发并在之后恢复？

耐久测试

在数小时内维持中等负载，以发现内存泄漏、未释放的连接或使系统逐渐变慢的数据堆积。

对大多数企业来说，在估算高峰下做负载测试，并用压力测试了解安全余量，这样的组合已经非常有价值。如果您运行带有突发触发点的活动，如通过社交媒体和直播电商销售所述，还应加上突发测试。

设定目标：必须服务多少用户

没有目标的测试毫无意义。从数据出发，而不是猜测。

• 历史数据：来自分析工具和服务器日志的上一次高峰的访客数、并发会话数和每分钟订单数
• 活动计划：预计的广告预算、邮件列表规模和网红覆盖面，换算成每小时的预计访问量
• 安全系数：将估计值翻倍或三倍，以便活动效果超出计划时仍有余地
• 突发形态：高峰持续多久，是突然还是渐进

将目标转化为可测试的数字，例如：系统必须服务五百名并发用户，商品页响应时间低于两秒；每分钟一百笔订单，错误率低于百分之一。整洁的分析数据，如用于决策的网站与移动应用分析中所述，会让这些数字更容易整理出来。

设计真实的场景

只有当场景与真实行为相似时，测试结果才有意义。用一千个请求冲击一个首页，说明不了任何问题。

• 构建用户旅程：从首页或广告进入，查看商品列表，使用搜索和筛选，打开商品详情，加入购物车，结账并付款
• 设定比例：并非每位访客都会走到付款。例如百分之九十只是浏览，百分之八装满购物车，百分之二完成购买。根据您的转化数据调整
• 包含数据多样性：不同商品、不同账号、不同搜索词，以免结果被缓存不切实际地帮了忙
• 同时包含在后台运行的流程，如库存同步、邮件发送和 ERP 更新，因为它们争夺相同的资源
• 谨慎处理第三方：支付网关和物流服务通常提供测试环境，或禁止对其生产系统做负载测试。请使用沙盒环境或模拟服务

关注对收入最关键的环节：搜索、购物车和结账，如网店结账：减少购物车放弃和网店商品搜索与筛选所述。对于促销，复杂的折扣规则也会加重系统负担；参见管理促销与折扣。

测量什么以及如何解读

平均响应时间可能产生误导，因为它掩盖了最慢用户的体验。请关注以下数字。

• 响应时间百分位：中位数显示一般体验，而第九十五和第九十九百分位显示不走运用户的体验。在销售高峰，二十位用户中有一位等待十秒，仍然意味着数百位顾客流失
• 错误率：失败请求的百分比。设定可接受的阈值，例如低于百分之一
• 吞吐量：每秒或每分钟成功处理的请求或订单数量
• 资源使用：每个组件上的 CPU、内存、数据库连接、磁盘 I/O 和网络，用以看出谁成了瓶颈
• 恢复行为：负载下降后系统恢复正常的速度

寻找拐点，即响应时间曲线开始急剧上升时的负载。这才是系统的有效容量，而不是服务器宕机前的最大数字。将其与目标比较，并记下最先饱和的组件。生产环境中良好的监控，如可观测性、日志与错误处理和企业网站与应用的监控与正常运行时间所述，为测试结果与现实之间提供了对比数据。

测试的环境、工具与安全

测试应在服务器规格、数据库规模、配置和网络都类似生产的环境中运行。在开发人员的笔记本或小型数据库上测试，得出的数字并不适用。用接近生产的数据量填充测试数据库，但使用虚构或匿名化的数据以保护机密，符合个人数据保护。

负载测试工具很多，有免费的也有收费的，通过脚本定义用户旅程。选择您的团队能使用的工具，并与发布流程集成，让轻量负载测试可以常规运行，如自动化测试与 CI/CD所述。对于非常大的负载，负载生成器需要分布式部署，以免自身成为瓶颈。

要注意几点，避免测试制造新问题。如果测试规模大，应通知托管提供商和第三方。不要在未经协调的情况下对生产系统发起负载测试，因为可能干扰真实顾客并触发封锁。未经许可不要测试第三方服务。还要小心副作用：测试不得向顾客发送真实邮件、产生真实支付交易或改变生产库存。

通常影响最大的修复措施

找到瓶颈后，修复措施大体可分为几类。

数据库

添加合适的索引，修复慢查询，减少重复查询，必要时用副本将读负载与写负载分开。许多高峰崩溃的案例，最终发现源自一条没有索引的查询。

缓存

存储经常被请求且很少变化的结果，如商品页、分类和配置。在内容分发网络层和应用中缓存，可大幅减轻服务器和数据库的负担。类似问题见网站速度及其影响和核心网页指标。

后台工作

把不必等待的重活，如发送邮件、更新 ERP 和生成发票，移到队列中，避免拖慢结账页面。这与企业 Webhook 与实时集成中的模式一致。

扩展与容量

横向增加服务器容量或使用自动扩缩容，但要确保应用组件确实能并排运行。注意成本，因为为一个高峰日全年保留多余容量是浪费。更经济的做法见企业云成本控制，基础设施选择见云端还是本地部署。

对局部故障的韧性

设计成一个组件的故障不会拖垮一切：对第三方调用设置超时、使用断路器，以及即使某些功能宕机页面仍可浏览。如果有排队入口或虚拟等候室，超出容量的用户会被有序安排，而不是以错误被拒绝。对于临近高峰发布的新功能，功能开关与分阶段发布让您能迅速关闭有问题的功能。

高峰日计划

负载测试只是一半的准备。还要为高峰日准备运营计划。

• 高峰前几天冻结代码变更，紧急修复除外
• 设置带有告警阈值和联系人的实时监控
• 准备职责明确的待命团队：谁监控、谁修复、谁与顾客沟通
• 准备经过测试的应急措施，如禁用重功能、启用排队页面或提升容量
• 准备出现故障时对顾客的沟通，并依据[灾难恢复与业务连续性计划](/blog/rencana-pemulihan-bencana-dan-kesinambungan-bisnis)制定恢复计划
• 事后评估：比较真实负载与估计，记录发生的情况，并更新下一次高峰的目标

常见错误

• 测试离促销日太近，没有时间修复
• 只测试首页，而不测试产生收入的旅程
• 使用比生产小得多的测试环境，再据此推断容量
• 只看平均响应时间
• 忘记有自己速率限制的第三方服务
• 修复了一个瓶颈，却不重复测试以找出下一个
• 代码或基础设施发生重大变更后没有重新测试

如何开始

从小处开始。选择最重要的一条旅程，通常是从商品到结账。根据上一次高峰的数据设定现实的目标，在测试环境中进行首次测试，并把结果记录为基线。修复最大的瓶颈，重复测试，并逐步扩大范围。在大型活动前大约四到六周安排测试，以留出足够的修复时间。之后让轻量负载测试成为常规发布的一部分。这种测试是对UAT：应用上线前的测试的补充，后者确认功能正确，而负载测试确认这些功能在繁忙时仍能撑住。关于支撑规模的架构，另见单体还是微服务。

常见问题

负载测试多久做一次？

至少在每次大型活动之前，以及代码、数据库或基础设施发生重大变更之后。对关键系统，在每次发布时进行轻量自动化测试，有助于尽早发现性能退化。

负载测试昂贵吗？

工具和测试环境的起步成本可以很低，尤其是使用开源工具和按小时租用的基础设施。主要成本是团队设计场景和修复发现的时间。可以与高峰日一小时故障中损失的潜在销售额比较。

我可以直接在生产环境测试吗？

在某些条件下可以，例如在非繁忙时段用隔离的测试数据做小负载，但风险更高。对于大负载，请使用类似生产的环境，并与托管提供商和第三方协调。

使用云服务是不是就不需要负载测试？

不是。自动扩缩容有帮助，但解决不了慢查询、数据库连接上限、第三方速率限制或无法并行运行的代码。负载测试恰恰能显示扩缩容是否真正有效。

结论

负载测试把不确定性变成数字：能服务多少用户，系统最先在哪里投降，哪些需要修复。有了来自真实数据的目标、与顾客行为相似的场景、高百分位的测量，以及足够的修复和重复时间，高峰日就从一场赌博变成一场排练过的事件。与它挽救的销售额相比，这项投入很小。