| 技术提示
大多数系统的构建目的是尽快服务用户。虚拟等待室则相反。它们的目的不是速度、吞吐量，甚至不是传统意义上的可用性。它们的目的是控制。它们存在的目的是放慢用户速度，让他们停留在原地，逐步放行，以防下游系统因压力而崩溃。 这种颠倒打破了团队在负载测试中带入的许多假设。对API或Web应用有意义的指标——响应时间、错误率、每秒请求数——对判断等待室在关键时刻是否表现正确几乎没有帮助。一个返回快速响应但悄无声息地丢失状态、违反顺序或不可预测地放行用户的队列并不健康。它是不稳定的。...
| 技术提示, 技术提示
负载测试存在认知问题。它仍然被广泛视为一种量化练习：多少用户，多少请求，多少吞吐量。这些数字易于配置、易于报告，并且易于在多次运行中比较。但这些数字是不完整的。 生产系统不会将“用户”视为静态数量。他们经历的是随时间变化的活动。请求不均匀到达。会话重叠。用户会暂停、重试、放弃流程，然后返回。某些会话简短且轻量，另一些则长时间存在且具状态。这些动态比峰值并发更能塑造基础设施的行为。...
| 技术提示
无头浏览器已悄然成为现代 Web 应用负载测试的默认执行模型。它们部署迅速、扩展成本低，并且易于集成到自动化流水线中。对于长期承受“更早测试、更频繁测试、更高并发测试”压力的团队而言，无头执行不仅显得务实，而且几乎不可避免。 然而，这种流行也带来了一个微妙的问题。许多团队在并未完全理解无头浏览器负载测试测量了什么——或更重要的是，遗漏了什么——的情况下就开始使用它。因此，组织越来越认为自己在测试面向用户的性能，而实际上测试的是更狭窄的内容：并发条件下的客户端逻辑执行。 这种区分至关重要。现代 Web...
| 技术提示
云账单的飙升并不是因为云服务定价过高，而是因为在真实流量到来时，服务的行为变得不可预测。在轻负载下运行 80 毫秒的函数，在并发情况下可能需要 200 毫秒。一个在预发布环境中看起来很干净的微服务，在繁忙时可能会扩散为五个内部调用。一套在安静下午感觉调校完美的数据库，在流量增强的瞬间可能就会触及 IOPS 上限。这些不是定价问题，而是只有负载测试才能揭示的行为问题。...
| 性能测试, 技术提示
当基础设施消失时，性能工程师所依赖的假设也随之消失。无服务器计算——通过 AWS Lambda、Azure Functions 和 Google Cloud Functions ——承诺无限的可扩展性和零运维。但在实践中，它把传统服务器的稳态负载模型替换为更动态且不可预测的模式。 一个函数可以在毫秒内从零扩展到数百个实例，然后同样迅速消失。C 缓存被重置。运行时重新初始化。指标分散在提供商的 API 中，而不是集中在系统仪表盘上。 这种弹性很强大——但它打破了所有传统的负载测试规则。...
| 性能测试, 技术提示
产品发布是数字服务生命周期中最不宽容的时刻。你可以花数月设计功能、数周打磨用户体验、在营销上投入数千美元，但如果发布后前30分钟内基础设施就出故障，结局不言自明：宕机、愤怒的用户以及被浪费的投入。与日常运营不同，发布会把流量压缩成单一且不可预测的峰值。这就是为什么面向产品发布的负载测试不是可选项——它决定了发布是丝滑顺畅，还是在自带的热度下崩溃。...
