管理應用程式資源

App Engine 會產生應用程式效能和資源使用率的使用報告。以下列出各種可能策略,協助您更有效率地管理資源。詳情請參閱定價頁面。

查看使用報告

評估應用程式效能時,您應檢查應用程式正在執行的執行個體數,以及應用程式耗用資源的方式。

查看資訊主頁使用報告

查看執行個體頁面

下面各節針對如何管理資源提供一些策略建議。

管理動態執行個體資源調度

減少延遲時間

應用程式延遲會影響處理流量所需的執行個體數量。降低延遲時間,就可以減少用來提供應用程式的執行個體數量。Stackdriver Trace 是一種非常有用的工具,可查看延遲的相關資料,以及瞭解減少延遲時間的可能變動。

使用 Stackdriver Trace 查看延遲後,請嘗試執行以下策略以減少延遲時間:

  • 增加頻繁存取共用資料的快取:也就是使用 App Engine Memcache。另外,設定應用程式的快取控制標頭,也會對伺服器和瀏覽器快取資料的效率帶來重大影響。即使是幾秒鐘的快取作業,也會對應用程式提供流量的效率造成影響。Python 應用程式也應充分利用執行階段快取功能
  • 更有效率地使用 App Engine Memcache:對於 get、set、delete 等指令採用批次呼叫,而非發出一連串的個別呼叫。 請考慮使用 Memcache Async API
  • 使用非要求繫結功能工作:如果應用程式可以執行超出使用者要求範圍的作業,請將其加入工作!在傳回回應前,與其等待工作完成,不如將此工作傳送至工作佇列,這麼做可以大幅減少使用者經歷的延遲時間。工作佇列可讓您更完善地掌控執行率,並協助減少負載。
  • 以更有效率的方式使用 Cloud Datastore:詳情請見下文的說明。
  • 同時執行多個網址擷取呼叫
    • 將多個網址擷取呼叫以批次處理,而不是在個別的使用者要求中分開處理,您可以透過非同步網址擷取以在離線工作中並行處理。
    • 使用非同步 URL Fetch API
  • 在 HTTP 工作階段中,以非同步方式寫入

變更自動調整資源配置的效能設定

app.yaml 設定檔含有數種設定,可用於調整特定版本應用程式效能和資源負載之間的平衡。如需可用的自動調整資源配置設定清單,請參閱資源調度元素一節。請觀看 App Engine 新排程器設定影片,以瞭解這些設定的效果。

啟用並行 Python 要求

您的應用程式執行個體可並行提供多個 Python 要求。啟用這個設定會降低為應用程式提供流量所需的執行個體數量,但必須確保應用程式的執行緒安全,這項設定才能正常運作。請參閱如何app.yaml 檔案中啟用執行緒安全以使用並行要求的說明。

指定工作佇列設定

工作佇列的預設設定已針對效能進行調整,如果使用這些預設值,當您將數個工作同時加入佇列時,很可能會導致系統啟動新的前端執行個體。以下針對如何調整工作佇列以節省執行個體時數提出一些建議:

  • 針對不容易受到延遲影響的工作,設定 X-AppEngine-FailFast 標頭。如果現有的執行個體無法使用,這個標頭會指示排程器讓要求立即失效。工作佇列將一直重試和輪詢,直到現有的執行個體可用於提供要求為止。但請務必注意,如果設定了 X-AppEngine-FailFast 的要求佔用現有的執行個體,則未設定該標頭的要求仍會導致系統啟動新的執行個體。
  • 指定工作佇列設定
    • 如果將「rate」參數設為較低的數值,工作佇列會以較慢的速度執行工作。
    • 如果將「max_concurrent_requests」參數設為較低的數值,則同時執行的工作數會較少。
  • 使用後端以完全控管執行工作時使用的執行個體數量。您可以將發送佇列與動態後端搭配使用,或將提取佇列與常駐後端搭配使用。

儘可能提供靜態內容

Python 提供的靜態內容是由特殊的 App Engine 基礎架構處理,不會耗用執行個體時數。如果您需要設定自訂標頭,請使用 Blobstore API。實際提供 Blob 回應時不會耗用執行個體時數。

管理應用程式儲存空間

App Engine 會依據 Cloud Datastore 中的實體大小、Cloud Datastore 索引大小、工作佇列中的工作大小,以及儲存在 Blobstore 的資料數量來計算儲存空間費用。您可以執行以下作業以確保不會儲存非必要資料:

  • 刪除應用程式不再需要的任何實體或 Blob。
  • 依照以下「管理 Datastore 使用情形」一節,移除任何不必要的索引以減少索引儲存空間費用。

管理 Cloud Datastore 使用情形

App Engine 會計入在 Cloud Datastore 中執行的作業數量。以下幾項策略可降低 Cloud Datastore 的資源消耗量,以及減少 Cloud Datastore 要求的延遲時間:

  • GCP 主控台資料檢視器會顯示在本機 Cloud Datastore 中建立每一個實體所需要的寫入作業數,您可以透過這項資訊瞭解寫入每個實體的費用。如要瞭解如何解譯此資料,請參閱瞭解寫入費用
  • 移除所有不必要的索引,以減少佔用的儲存空間和實體寫入費用。使用「取得索引」功能查看在應用程式中定義的索引。 如要查看目前提供給應用程式的索引,請參閱 GCP 主控台搜尋頁面
  • 設計資料模型時,您或許可以使用這樣的方式來撰寫查詢,以避免使用自訂索引。如要進一步瞭解 App Engine 如何產生索引,請參閱查詢與索引說明文件。
  • 儘可能以未建立索引的屬性 (Python) 取代已建立索引的屬性 (預設值),這樣可以在您加入實體時減少 Cloud Datastore 寫入作業數量。請注意,如果您日後決定確實需要查詢未編入索引的屬性,則不僅需要修改程式碼才能再次使用已編入索引的屬性,還必須對所有實體執行 map reduce 以重新加入。
  • 我們已改進 App Engine 1.5.2 及 1.5.3 版中的 Cloud Datastore 查詢規劃工具,因此現在查詢需要的索引數可能比之前少。雖然您可能還是會為了維持效能而選擇保留某些自訂索引,但您可以刪除其他索引,以減少儲存空間和實體寫入費用。
  • 請重新設定資料模型,以便利用鍵擷取代替查詢,不但成本較低,效率也更高。
  • 如果可能,請使用僅限鍵查詢代替實體查詢。
  • 如要減少延遲時間,請將多個實體 get() 替換成批次 get()
  • 使用 Cloud Datastore 游標進行分頁而非偏移。
  • 透過 Async Datastore API 平行處理多個 Cloud Datastore 遠端程序呼叫 (RPC)。

注意:小型 Cloud Datastore 作業含有配置 Cloud Datastore ID 或僅限索引鍵查詢的呼叫。如要進一步瞭解費用,請參閱定價頁面。

管理頻寬

如要降低連出頻寬的使用量,可在回應中設定適當的 Cache-Control 標頭並針對靜態檔案設定合理的到期時間。透過這種方法使用公開 Cache-Control 標頭,可允許 Proxy 伺服器和用戶端瀏覽器在指定的時間範圍內快取回應。

連入頻寬涉及使用者傳送到應用程式的資料量,因此較難掌控。不過,這時正好可採用 DoS 保護服務,針對您認為違規的 IP 封鎖流量。

管理其他資源

稽核 Email API 使用量的其中一個最佳策略,是使用 Appstats 確保您進行的呼叫數沒有超過所需。理想的做法是確保持續檢查錯誤率,並尋找您可能進行任何無效的呼叫。在某些情況下,也許可以及早找出這些呼叫。

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Python 2 適用的 App Engine 標準環境