应用引擎自动缩放配置

Posted 2023-03-04

【中文标题】应用引擎自动缩放配置

【英文标题】：App engine automatic_scaling configuration

【发布时间】：2015-12-31 18:48:52

【问题描述】：

我正在尝试通过设置 automatic_scaling 参数来减少我的 Google App Engine 费用。平均而言，我的应用程序有 7-10 个实例正在运行，其中 2 或 3 个是空闲的。但有时，就像附表中的凌晨 3 点到 6 点之间，活动实例和空闲实例之间的差异大得离谱。另外，我想减少活动实例的数量，从而增加最终用户的响应时间（设置min_pending_latency 和max_pending_latency）。但是，到目前为止，这些设置都没有任何效果。

这是我的 app.yaml 配置：

automatic_scaling:
  min_pending_latency: 250ms
  max_pending_latency: 750ms
  max_idle_instances: 2

【参考方案1】：

同时设置min_pending_latency 和 max_pending_latency 会向自动缩放器发送混合消息。

更一般地说，您可以调整自动缩放器以包含您的成本（为max_idle_instances 设置一个较低的值和/或为min_pending_latency 设置一个较高的值），或 em> 以提高您的可扩展性——也就是说，为流量激增保持低延迟（为min_idle_instances 设置一个高值和/或为max_pending_latency 设置一个低值）。

不要混合使用这两种调整——根据我的经验，这种“混合消息”永远不会对成本或激增期间的延迟产生良好的影响。

是的，我正在努力让这些基本信息成为 Google Cloud Platform 官方文档的一部分——这比我希望的要花更长的时间，这就是为什么我同时发布这个答案。

如果您对随时间推移的流量模式、激增的可能性等非常确定的话，一个更高级的选择是从自动缩放模块切换到基本缩放甚至手动缩放模块，编写您自己的代码通过Modules API 启动和终止实例。

尽管如此，我不得不承认，对于专门为用户流量提供服务的模块（与任务队列或基于 cron 的“后端”工作相反），这对我来说从来都不是最佳效果——我的用户激增和时间模式从来没有正如分析过去的记录所暗示的那样，未来的发展是可以预测的。所以，最后，我总是回到（用于用户流量服务）良好的旧自动缩放，也许通过适度的调整要么降低成本，或改进可扩展性，正如我上面推荐的那样。

【讨论】：

那么，您认为这是控制成本的好配置吗？ automatic_scaling: min_pending_latency: 500ms max_idle_instances: 2

@JavierMarín，是的，我相信与默认的 auto 缩放相比，它可能会降低成本（取决于使用中激增的形状和频率）。