優化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/