负载测试：它们是什么以及为什么您的系统应该在客户端之前执行它们

每个系统都可以与一个用户很好地配合。问题是从同时有一千个开始的。

大多数团队都会以最糟糕的方式发现自己系统的局限性：在生产中，在高峰期，在客户的注视下。这场运动爆发了，这篇文章疯传了，纳税截止日期到了，看似强劲的经济崩溃了，因为没有人衡量过它能持续多久。

负载测试的存在就是为了颠倒这个顺序。用户不是偶然发现限制，而是在受控环境中有意发现它，以免造成伤害。

负载测试到底是什么

负载测试使系统受到越来越多的请求或并发用户的影响，以衡量系统在需求下的表现。他回答的问题不是“它有效吗？”，而是“它对多少人有效？”。

注意差异。功能测试验证功能是否正确。负载测试可检查当许多人同时使用它时它是否保持正确和快速。这些是不同的问题，第二个问题只是按规模出现。

您可以模拟实际数量的用户执行实际操作、登录、搜索、结账，并观察负载增加时的响应时间、错误率和资源使用情况。结果是系统如何退化的描述。

值得将经常混淆的术语分开，因为每个术语都回答不同的问题。

负载测试衡量预期和不断增长的需求下的行为，系统以可接受的质量支持多少并发用户。压力测试故意过度，以了解系统如何崩溃和恢复。从广义上讲，性能测试通常在某些负载下测量响应时间和效率。

Cargo回应“能按预期坚持下去吗？”压力回答“极端情况下会发生什么？”。将它们在你的头脑中分开，可以防止错误的测试得出错误的结论。

人们很容易将货物视为工程细节。这是一个错误。您的系统容量限制是您可以同时服务的客户数量的限制，而这纯粹是业务问题。

想象一下在特定日期开放职位空缺的公共调度服务。所有符合条件的人口都在同一时间窗口内抵达。如果没有人测试过负载，系统就会在最重要的时候崩溃，并且该故障会成为头条新闻。成本不是技术性的；受到制度上的信任。

对于准备发布的初创公司来说也是如此。投资媒体以带来流量激增，并在高峰时让网站离线，这会烧钱两次：媒体和声誉。

明显的指标是响应时间和错误率。它们很重要，但它们只讲述了故事的一部分。

平均天气是骗人的。良好的平均值可以隐藏一小部分体验不佳的用户。这就是为什么我关注百分位数，即 5% 或 1% 经历最差的时间，而不是平均值。这才是真正的挫败感所在。

另外，查看背后的资源：CPU 使用率、内存、bank 连接、请求队列。通常，瓶颈不是应用程序服务器，而是 [数据库0 或大小不足的连接池。负载测试不仅显示其性能下降；仪器齐全，显示位置。

第一个错误是在看起来不像生产环境的环境中进行测试。在小型机器上或在空库上运行负载会产生漂亮但无用的数字。测试环境必须具有代表性，数据量必须与真实数据相似。

二是模拟不真实的用户。同一端点上的一千个相同请求不能反映人类行为。真实用户浏览、思考、重复操作、放弃。有效负载场景重现了这种模式，而不是统一的机器人。

第三种，也是最常见的一种，是在发布前测试一次，然后不再测试。容量不是静态的。每个新功能、每个对银行的新查询都可以更改限额。非重复负载测试的有效期很短。

并非每个系统从第一天起就需要进行负载测试。十个人使用的内部产品并不能证明这种努力是值得的。正确的问题是关于尖峰暴露。

如果您的系统具有可预测的集中需求时刻、活动、截止日期、发布、季节性或快速基数增长，则负载测试不再是可选的。第一次测量的最佳时间是在第一个大峰值之前，而不是之后。

我提倡的心态转变很简单：能力是一种要求，而不是意外。了解系统的上限与了解系统是否实现其承诺同样重要。有人告诉你它有效；有人告诉你它有效；有人告诉你它有效。另一个告诉你成功到来时它会持续工作多长时间。

如果您的组织即将发生峰值事件，并且没有人确定系统是否可以处理它，那么这种风险值得提前解决，而不是在过程中解决。我在博客上还有其他关于性能、可扩展性和可靠性的文章与此相关。