优化Google App Engine的应用程序体系结构和实现

Question

据我了解，GAE的计费全部归结为实例小时数 （“ IH”），或在一定时间内运行了多少个服务器实例。 但是，这显然不是那么简单，因为除了IH之外，您还必须在一天的整个过程中保持配额和资源限制（因为配额每24小时会补充一次）。

我正在设计我的第一个GWT / GAE应用程序，并且遇到了许多文章（下面引用了其中的一些文章），在这些文章中，作者谈论了他们必须对代码进行的重大重构-发布后-以帮助与Google最大限度地减少结算和运营成本。

在一个实例中，开发人员对其GAE应用程序进行了一系列优化，导致同一应用程序从每天7美元（约合每月220美元）下降到0美元，因为它最终处于“免费”配额和资源计费阈值以下。

对于GAE而言，它是如此陌生，我想知道是否有任何原则或实践可以整合到我的应用程序的架构/设计中，一旦被扎入到已实现的功能代码中并部署到GAE，将会导致该应用程序以尽可能高效地运行（以语言进行交流）。

到目前为止，我做了一些推断：

• 最大化缓存并最小化数据存储命中
• 尝试将尽可能多的异步请求处理推送到后端实例
• 启用并发HTTP请求处理，以便同一实例可以同时处理多个请求

所以我的问题是：我对这些归纳法中的任何一项都做错了吗？如果是，为什么？ 我在这里错过任何重要的东西吗？ 例如，如何确定哪些代码属于后端实例（资源约束更为宽松），如何利用GAE特定的分析工具（AppStats，SpeedTracer等）来查看瓶颈等。

另外，一些引用的文章：

• 配置最大空闲和最小延迟
• GAE自己的扩展最佳实践
• CPU优化示例

Answer 1

根据经验，适用于App Engine优化的策略有很多，其适用性取决于您应用的性质。 以下是一些我所知道的提示：

• 对于提供大量相对静态内容的应用程序， 启用（尚未记录的）边缘缓存可能是您每周账单的一大福音。

• 即使启用了并发请求/线程安全 ，在调度程序决定为您启动一个新实例之前，每个前端实例也只能处理8个（对于Python）到10个（Java，Go）同时传入的请求 。

• 为了克服上述限制，我认为有一个Google I / O视频建议您将前往前端实例的任何面向用户的请求的响应时间减少到100毫秒。

• 根据上述策略，如果您有任何需要大量处理或数据存储I / O的任务，请将任务卸载到推送任务队列中 ，然后立即响应请求。 您可以指定任务队列的目标 ，但是为此，它不必是后端，前端实例足够好，并提供无限的可伸缩性。

• 如果您使用上述策略，但仍需要将处理或I / O的结果提供给用户，请使用Channel API或任何其他消息传递服务将结果异步发送回。

• 任务队列是分发应用程序工作负载的绝佳工具。 您可以详细自定义其行为 ，它们对于确保应用程序可扩展性非常宝贵。 您甚至可以使用推和拉队列在实例之间进行双向通信。

_{稍后再添加更多点。}

Answer 2

在大多数情况下，成本优化将针对您的应用。 由于您在询问一般原则，因此它们通常适用于CPU和数据存储。

中央处理器：

提防为停滞的CPU付款。 如果您的CPU在长时间的操作（缓慢的数据存储请求或URL提取等）上停滞不前，则App Engine可能会启动另一个实例，从而增加了成本。 为此，有许多策略-启用线程，任务队列。 我怀疑当您谈论将异步请求放在后端时，它也可以解决此问题。 有多种处理方法。

数据存储：

1. 仔细控制索引。 索引对您的成本有很大贡献。

2. 精心设计数据存储区，以最大程度地减少所需的请求数量。

3. 非正规化。 对于NoSQL数据存储，非规范化是非常标准的过程。 本质上，这意味着在必要时将重复数据存储在多个实体中。 这样可以在App Engine上节省$，因为您可以按请求付费，但不必为返回的实体大小付费。 例如，如果您有出售小部件的商店，则您可能希望将所有单个商店小部件的摘要版本存储在Store实体中（前提是它应符合1MB实体限制）。 这样，当显示商店的页面时，您仅获取一个商店实体，而不是商店实体加上每个小部件实体。 同样，如果您需要计算小部件的数量，则最好在商店实体中拥有该值，而不是发出查询以获取该数量。

缓存：

缓存可以节省CPU和数据存储方面的成本。 有一个来自Google IO的不错的视频： https : //developers.google.com/events/io/sessions/gooio2012/310/