App引擎automatic_scaling配置

Question

我试图通过设置automatic_scaling参数来降低Google的开销。平均而言，我的应用程序有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

​

​

Answer 1

设置min_pending_latency和max_pending_latency都会向自动分词器发送混合消息。

更广泛地说，您可以调整自动分词器以控制成本(为max_idle_instances设置一个较低的值和/或为min_pending_latency设置一个较高的值)，或者提高您的可伸缩性--即在流量激增时保持低延迟(为min_idle_instances设置一个高值和/或为max_pending_latency设置一个较低的值)。

不将这两种调整混合在一起--在我的经验中，这种“混合消息”不会在波动期间对成本或延迟产生好的影响。

是的，我 am 致力于让这些基本信息成为Google平台官方文档的一部分--它所用的时间比我想象的要长，这就是为什么我同时发布这个答案的原因。

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

尽管如此，我不得不承认，这对我来说从来都不是最有效的，对于致力于服务用户流量的模块(相对于任务队列或基于cron的“后端”工作) --我的用户的激增和时间模式从没有像分析过去记录时所建议的那样可预测。因此，最后，我总是回到(为用户流量服务)良好的旧自动缩放，也许通过适度的调整，要么降低成本，要么提高可伸缩性，正如我上面所建议的。