6

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

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

在一个例子中，开发人员对其 GAE 应用程序实施了一组优化，导致同一应用程序从每天 7 美元（约 220 美元/月）降至 0 美元，因为它最终低于资源的“免费”配额和计费阈值.

作为 GAE 的新手，我想知道是否有任何一组原则或实践可以预先融入我的应用程序的架构/设计中，一旦渗透到已实现的功能代码并部署到 GAE，将导致应用程序尽可能高效地运行（从金钱上讲）。

以下是我到目前为止所做的一些推论：

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

所以我的问题是：我所做的这些概括是否不正确，如果是，为什么（或者它们是有条件的，在某些情况下它们成立但在其他情况下不成立）？我在这里遗漏了什么重要的东西吗？例如，如何确定哪些代码属于后端实例（资源限制稍微宽松一点），使用哪种 GAE 特定的分析工具（AppStats、SpeedTracer 等）来查看瓶颈等。

此外，一些引用的文章：

4

2 回答 2

2

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

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

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

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

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

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

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

稍后我会添加更多的点。

于 2012-08-23T06:22:39.740 回答
0

大多数情况下，成本优化将特定于您的应用程序。由于您询问的是一般原则，它们主要适用于 CPU 和数据存储。

中央处理器：

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

数据存储：

  1. 仔细控制你的索引。索引会大大增加您的成本。

  2. 仔细设计您的 datstore，以尽量减少您需要的请求数量。

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

缓存：

缓存可以在 CPU 和数据存储方面为您节省资金。来自 Google IO 的一段非常棒的视频： https ://developers.google.com/events/io/sessions/gooio2012/310/

于 2012-08-23T15:38:10.853 回答