我的理解是GAE上的结算都归结为 instance-hours （“IH”），或者在一段时间内运行了多少个服务器实例。但是，显然不是 简单，因为除了IH之外，您还必须在一天中充分利用配额和资源限制（因为配额每24小时补充一次）。
我正在设计我的第一个GWT / GAE应用程序，并且发现了许多文章（其中一些在下面引用），作者谈论他们必须对他们的代码进行的重大重构 - 发布后 - 为了帮助您最大限度地降低Google的结算和运营成本。
在一个实例中，开发人员对他的GAE应用实施了一系列优化，导致同一个应用从7美元/天（约220美元/月）下降到0美元，因为它最终处于“免费”配额和结算资源门槛。
对GAE这么新，我想知道是否有任何一套原则或实践可以融入我的应用程序的架构/设计中，这些原理或实践一旦渗透到已实现的功能代码中并部署到GAE，使应用程序尽可能高效地运行（货币化）。
以下是我迄今为止所做的一些推论：
所以我的问题是：这些概括我是不正确的，如果是这样，为什么（或者它们是有条件的，在某些情况下它们适用但在其他情况下不适用）？我错过了任何关键的东西吗？例如，如何确定后端实例上的代码是什么（资源约束稍微松散），利用哪种GAE特定的分析工具（AppStats，SpeedTracer等）来查看瓶颈等。
另外，引用了一些文章：
答案 0 :(得分：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，它们对于确保您的应用可以很好地扩展非常宝贵。您甚至可以使用推送和拉取队列在实例之间进行双向通信。
我稍后会添加更多积分。
答案 1 :(得分：0)
大多数情况下，费用优化将针对您的应用。由于您询问的是一般原则，因此它们主要适用于CPU和数据存储区。
CPU：
注意支付停滞的CPU费用。如果您的CPU在长时间操作（缓慢的数据存储请求或URL提取等）上停滞不前，App Engine可能会启动另一个实例，从而增加您的成本。这有很多策略 - 启用线程，任务队列。我怀疑当你谈到将异步请求放在后端时，它也是为了解决这个问题。有多种方法可以解决这个问题。
数据存储：
仔细控制索引。索引对您的成本贡献很大。
仔细设计您的数据存储，以尽量减少您需要的请求数。
进行非标准化。非规范化是NoSQL数据存储的标准过程。实质上，它意味着在必要时将重复数据存储在多个实体中。这样可以节省App Engine上的$，因为您按要求付费，但是您不需要支付所返回实体的大小。例如，如果您有销售小部件的商店，您可能希望在商店实体内存储所有单个商店小部件的摘要版本（前提是它符合1MB实体限制）。这样，当您显示商店的页面时，您只获取一个商店实体，而不是商店实体加上每个小部件实体。 同样，如果您需要计算小部件的数量，最好在商店实体中包含该值，而不是发出查询以获取计数。
缓存：
缓存可以节省CPU和数据存储端的费用。有一个来自Google IO的非常好的视频： https://developers.google.com/events/io/sessions/gooio2012/310/