Web容量规划之美

109

测量

：

容量的单位

通过定期收集这些信息，你已经足够了解

API

使用量如何影响资源。你可以在容

量变化时调整

API

的上限。

示例和现实

每个应用程序和数据类型对系统资源的影响不同。本章的示例简单阐述了方法和

思考过程，通过它你可以研究并更好了解增加的负载如何影响你的基础架构的每

一部分。从中吸取的重要经验是，基础架构的每一部分将花费系统资源来为网站

服务，你应该确保对这些资源进行适当的测量。然而，记录正确的测量并不足够。

你还需要知道何时那些资源将耗尽，这也是为什么你需要定期地探测并建立这些

上限。这是特别重要的，敏捷开发的一个给定的应用程序或是微服务在短时间内

有重大改变的性能概况。

通过寻找基础架构上限的实践过程，可暴露出你甚至不知道的瓶颈。基于此，你

可能需要改变应用程序、硬件、网络或造成问题的其他部分。每次你对基础架构

做一次修改，你需要再次检查上限，因为它们也很有可能改变，这不应该令人惊奇，

因为现在你知道容量规划是一个过程，而不是一次性的事件。

小结

测量是必须的，而不是可选的。它应该是被看作基础架构的重要部分。它可以贯

穿到组织的各部分：财务、客户服务、工程和产品管理。

没有测量和你的系统、应用层度量指标的历史数据，则容量规划无法存在。不知

道你系统的最高性能上限但又想避免接近上限，则规划也是没有效果的。要找到

基础架构每部分的上限，需要下面这些步骤：

1.

测量并记录服务器的主要功能。

示例：

Apache

命中、数据库查询。