我正在尝试通过设置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
设置两者min_pending_latency 并将 max_pending_latency混合消息发送到自动缩放器。
更一般地说，您可以调整自动缩放器以控制您的成本（为 设置一个低值max_idle_instances和/或一个高值min_pending_latency），或者提高您的可扩展性——也就是说，为流量激增保持低延迟（设置一个高值和min_idle_instances/或低一个max_pending_latency）。
不要混合这两种调整——根据我的经验，这种“混合消息”永远不会对成本或激增期间的延迟产生良好的影响。
是的，我正在努力让这些基本信息成为谷歌云平台官方文档的一部分——这比我希望的要长，这就是为什么我同时发布这个答案。
如果您对随时间推移的流量模式、激增的可能性等非常确定，则更高级的替代方法是从自动缩放模块切换到基本缩放甚至手动缩放模块，编写您自己的代码通过Modules API启动和终止实例。
虽然，我不得不承认，这对我来说从来都不是最佳的，对于专门为用户流量提供服务的模块（而不是任务队列或基于 cron 的“后端”工作）——我的用户的激增和时间模式从来都不是可预测的展望未来，正如分析过去的记录所暗示的那样。所以，最后，我总是回到（用于用户流量服务）良好的旧自动缩放，也许像我上面建议的那样，通过适度的调整来降低成本或提高可伸缩性。