IAm*_*aja 6 java architecture optimization google-app-engine
我的理解是GAE上的计费都归结为实例小时("IH"),或者在一段时间内运行了多少服务器实例.然而,它显然不是那么简单,因为除了IH之外,您还必须在一天中充分利用配额和资源限制(因为配额每24小时补充一次).
我正在设计我的第一个GWT/GAE应用程序,并且遇到了许多文章(其中一些在下面引用),作者谈论他们必须对他们的代码进行重大重构 - 发布后 - 以帮助通过Google降低结算和运营成本.
在一个实例中,开发人员对他的GAE应用程序实施了一组优化,导致相同的应用程序从每天7美元(约220美元/月)下降到0美元,因为它最终处于资源的"免费"配额和计费阈值之下.
作为GAE的新手,我想知道是否有任何原则或实践我可以预先整合到我的应用程序的架构/设计中,一旦进入已实现的功能代码并部署到GAE,将导致应用程序尽可能有效地(货币说话)运行.
以下是我迄今为止所做的一些推论:
所以我的问题是:这些概括我是不正确的,如果是这样,为什么(或者它们是有条件的,它们在某些情况下适用而在其他情况下不适用)？我错过了任何关键的东西吗？例如,如何确定后端实例上的代码(资源约束稍微松散),使用哪种GAE特定的分析工具(AppStats,SpeedTracer等)来查看瓶颈等.
另外,一些引用的文章:
根据经验，有大量的 App Engine 优化策略，其适用性取决于应用程序的性质。以下是我所知道的一些其他提示：
对于提供大量相对静态内容的应用程序，启用（尚未记录的）边缘缓存可能会减少您每周的账单。
即使启用了并发请求/线程安全，每个前端实例在调度程序决定为您启动新实例之前也只能处理 8 个（对于 Python）到 10 个（Java、Go）同时传入的请求。
为了应对上述限制，我认为有一个 Google I/O 视频建议您将任何面向用户的请求发送到前端实例的响应时间减少到约 100 毫秒。
根据上述策略，如果您有任何需要大量处理或数据存储 I/O 的任务，请将任务卸载到推送任务队列，并立即响应请求。您可以指定任务队列的目标，但为此目的，它不需要是后端，前端实例就足够好了，并且提供无限的可扩展性。
如果您使用上述策略，但仍需要将处理或 I/O 的结果提供给用户，请使用Channel API或任何其他消息服务将结果异步发送回来。
任务队列是分配应用程序工作负载的神奇工具。您可以详细自定义其行为，它们对于确保您的应用程序良好扩展非常宝贵。您甚至可以使用推队列和拉队列在实例之间进行双向通信。
稍后我会添加更多要点。