我的理解是，GAE上的结算都可以归结为实例小时（"IH"），或者在一段时间内运行了多少个服务器实例 . 然而，它显然不是那么简单，因为除了IH之外，您还必须在一天中充分利用配额和资源限制（因为配额每24小时补充一次） .
我正在设计我的第一个GWT / GAE应用程序，并且遇到了许多文章（其中一些在下面引用），作者谈论他们必须对他们的代码进行重大重构 - 发布后 - 以帮助通过Google降低结算和运营成本 .
在一个实例中，开发人员对他的GAE应用程序实施了一组优化，导致相同的应用程序从每天7美元（约220美元/月）下降到0美元，因为它最终处于资源的“免费”配额和计费阈值之下 .
作为GAE的新手，我想知道是否有任何原则或实践我可以预先整合到我的应用程序的架构/设计中，一旦进入已实现的功能代码并部署到GAE，将导致应用程序尽可能有效地（货币说话）运行 .
以下是我迄今为止所做的一些推论：
-
最大化缓存并最小化数据存储命中
-
尝试尽可能多地将异步请求处理推送到后端实例
-
启用并发HTTP请求处理，以便同一实例可以同时处理多个请求
所以我的问题是：这些概括我是不正确的，如果是这样，为什么（或者它们是有条件的，它们在某些情况下适用而在其他情况下不适用）？我错过了任何关键的东西吗？例如，如何确定后端实例上的代码（资源约束稍微松散），使用哪种GAE特定的分析工具（AppStats，SpeedTracer等）来查看瓶颈等 .
另外，一些引用的文章：
2 回答
根据经验，App Engine优化策略有很多，其适用性取决于应用程序的性质 . 以下是我所知道的一些提示：
对于提供大量相对静态内容的应用，enabling the (as yet undocumented) edge caching可能是您每周账单的祝福 .
即使启用了concurrent requests/threadsafe，在调度程序决定为您启动新实例之前，每个前端实例could only process 8 (for Python) to 10 (Java, Go) simultaneous incoming request也是如此 .
为了对抗上述限制，我认为有一个Google I / O视频建议您将面向前端实例的任何面向用户的请求的响应时间缩短为~100 ms .
根据上述策略的调整，如果您有任何需要大量处理或数据存储I / O的任务，请将任务卸载到push task queue，并立即响应请求 . 您可以指定target of the task queue，但为此目的，它不需要是后端，前端实例足够好，并提供无限的可伸缩性 .
如果您使用上述策略但仍需要向用户提供处理或I / O的结果，请使用Channel API或任何其他消息传递服务以异步方式发回结果 .
任务队列是分发应用程序工作负载的绝佳之选 . 你可以customize its behavior in detail，它们对于确保你的应用程序可以很好地扩展是非常宝贵的 . 您甚至可以使用推送和拉取队列在实例之间进行双向通信 .
我稍后会添加更多积分 .
大多数情况下，成本优化将特定于您的应用 . 由于您询问的是一般原则，因此它们主要适用于CPU和数据存储区 .
中央处理器：
注意关于支付停滞的CPU的费用 . 如果您的CPU在长时间操作（缓慢的数据存储请求或URL提取等）上停滞不前，App Engine可能会启动另一个实例，从而增加您的成本 . 这有很多策略 - 启用线程，任务队列 . 我怀疑当你谈到将异步请求放在后端时，它也是为了解决这个问题 . 有多种方法可以解决这个问题 .
数据存储：
仔细控制索引 . 索引对您的成本贡献很大 .
仔细设计您的数据存储，以最大限度地减少您需要的请求数 .
Denormalize . 非规范化是NoSQL数据存储的标准过程 . 实质上，它意味着在必要时将重复数据存储在多个实体中 . 这样可以节省App Engine上的$，因为您按要求付费，但您不需要支付所返回实体的大小 . 例如，如果您有销售小部件的商店，您可能希望在商店实体内存储所有单个商店小部件的摘要版本（前提是它符合1MB实体限制） . 这样，当您显示商店的页面时，您只获取一个商店实体，而不是商店实体加上每个小部件实体 . 同样，如果您需要计算小部件的数量，最好在商店实体中包含该值，而不是发出查询以获取计数 .
缓存：
缓存可以节省CPU和数据存储端的费用 . 来自Google IO的视频非常好：https://developers.google.com/events/io/sessions/gooio2012/310/