要求的處理方式

本文件說明 App Engine 應用程式如何接收要求及傳送回應。詳情請參閱要求標頭和回應參考資料

如果您的應用程式使用這些服務,則可以設定要求的位址,將要求傳送到特定服務或該服務的特定版本。如要進一步瞭解服務的定址功能,請參閱要求的轉送方式一文。

處理要求

您的應用程式負責啟動網路伺服器和處理要求。您可以使用任何適用於您的開發語言的網路架構。

App Engine 會執行應用程式的多個執行個體,每個執行個體都有自己專用的網路伺服器來處理要求。每個要求均有可能轉送至任何一個執行個體,因此來自同一個使用者的連續要求不一定會送到相同的執行個體。執行個體可以並行處理多個要求,而執行個體的數量能夠隨流量自動調整。您也可以變更執行個體可處理的並行要求數量,方法是在 app.yaml 檔案中設定 max_concurrent_requests 元素。

配額與限制

App Engine 會在流量增加時自動分配資源給您的應用程式,然而這項作業會受到下列限制:

  • App Engine 會針對低延遲時間 (回應要求的時間不到一秒) 的應用程式,保留自動調整資源配置的容量。如為具有高延遲時間 (例如在多個要求中,每個要求的回應時間超過一秒) 及高總處理量的應用程式,則需要白銀級、爍金級或白金級的支援。選用這類支援等級的客戶可與支援代表聯絡,要求提高總處理量上限。

  • 大幅受到 CPU 限制的應用程式可能也會產生一些額外的延遲時間,以便和相同伺服器上的其他應用程式有效率地共用資源。對靜態檔案的要求則不受這些延遲限制。

每個傳送至應用程式的要求均會計入「Requests」(要求) 限制,而回應要求所傳送的資料則會計入「Outgoing Bandwidth (billable)」(連出頻寬 (可計費)) 限制。

HTTP 及 HTTPS (加密連線) 要求均會計入「Requests」(要求)、「Incoming Bandwidth (billable)」(連入頻寬 (可計費)) 及「Outgoing Bandwidth (billable)」(連出頻寬 (可計費)) 的限制。GCP 主控台的「Quota Details」(配額詳細資料) 頁面也會分別顯示「Secure Requests」(安全性要求)、「Secure Incoming Bandwidth」(安全連入頻寬) 和「Secure Outgoing Bandwidth」(安全連出頻寬) 的值,以供參考之用。僅有 HTTPS 要求會計入這些值。詳情請參閱配額頁面。

下列限制專門適用於要求處理常式:

限制 數量
要求大小 32 MB
回應大小 32 MB
要求持續時間 60 秒
檔案總數量的上限 (應用程式檔案和靜態檔案) 總計 10,000 個
每個目錄 1,000 個
應用程式檔案的大小上限 32 MB
靜態檔案的大小上限 32 MB
所有應用程式和靜態檔案的全部大小上限 前 1 GB 免費
前 1 GB 過後,每個月每 GB $ 0.026

回應限制

動態回應限制為 32MB。如果指令碼處理常式產生大於此上限的回應,伺服器會傳回空白回應並顯示「500 Internal Server Error」(內部伺服器錯誤) 狀態碼。這項限制不適用於從 Blobstore 或 Cloud Storage 提供資料的回應。

要求標頭

傳入 HTTP 要求包含用戶端傳送的 HTTP 標頭。基於安全性考量,部分標頭在送達應用程式之前會由中繼 Proxy 進行處理或修改。

詳情請參閱要求標頭參考資料

要求回應

您產生的回應會受到一些限制,而且在傳回用戶端前可能已經過修改。

詳情請參閱要求回應參考資料

串流回應

針對在處理要求時以增量區塊傳送給用戶端的資料,App Engine 不支援其串流回應。系統會依上述方式收集所有來自您程式碼的資料,並做為單一 HTTP 回應傳送。

回應壓縮

如果用戶端傳送含有原始要求的 HTTP 標頭,指出用戶端可接受壓縮 (使用 gzip 格式壓縮) 的內容,App Engine 會自動壓縮處理常式回應資料,並附加適當的回應標頭。它會同時使用 Accept-EncodingUser-Agent 要求標頭,以判斷用戶端是否能穩定接收壓縮的回應。

自訂用戶端可使用 Accept-Encoding 值來指定 User-Agentgzip 標頭,藉此指出他們能夠接收壓縮的回應。回應的 Content-Type 也能用來判斷壓縮作業是否合適。一般來說,系統會壓縮文字內容類型,但不會壓縮二進位內容類型。

自動壓縮回應時,App Engine 會將 Content-Encoding 標頭新增至回應。

指定要求期限

要求處理常式通常要在大約 60 秒的時間限制內對要求產生並傳回回應。期限一到,要求處理常式就會中斷。

雖然要求的回應時間最長可達 60 秒,但 App Engine 會針對要求停留時間短暫的應用程式進行最佳化,尤其是回應要求只需耗費數百毫秒的應用程式。效率良好的應用程式能夠針對大部分的要求快速回應。而無法快速回應的應用程式,將無法隨著 App Engine 的基礎架構妥善調整規模。

如要瞭解常見的 DeadlineExceededError 原因和我們建議的解決方法,請參閱處理 DeadlineExceededErrors 一文。