要求的處理方式

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

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

處理要求

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

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

當 App Engine 收到應用程式的網路要求時,即會呼叫與該網址對應的處理常式指令碼,如應用程式的 app.yaml 設定檔所述。Python 2.7 執行階段針對回溯相容性支援 WSGI 標準CGI 標準。建議使用 WSGI,如果沒有它,Python 2.7 的某些功能就無法運作。應用程式的處理常式指令碼設定會決定使用 WSGI 還是 CGI 處理要求。

下列 Python 指令碼會使用 HTTP 標頭和「Hello, World!」訊息來回應要求。

import webapp2

class MainPage(webapp2.RequestHandler):
    def get(self):
        self.response.headers['Content-Type'] = 'text/plain'
        self.response.write('Hello, World!')

app = webapp2.WSGIApplication([
    ('/', MainPage),
], debug=True)

如要同時向每個網路伺服器分派多個要求,請把 threadsafe: true 新增到您的 app.yaml 檔案,並將應用程式標示為具「執行緒安全」。如有任何處理常式指令碼採用 CGI,則無法使用並行要求。

配額與限制

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

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

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

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

HTTP 及 HTTPS (加密連線) 要求均會計入「Requests」(要求)、「Incoming Bandwidth (billable)」(連入頻寬 (可計費)) 及「Outgoing Bandwidth (billable)」(連出頻寬 (可計費)) 的限制。GCP Console 的「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 美元

回應限制

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

要求標頭

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

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

要求回應

App Engine 會使用 Request 呼叫處理常式指令碼,然後等候指令碼傳回結果;所有寫入標準輸出串流的資料會以 HTTP 回應格式送出。

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

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

串流回應

若資料在要求處理過程中,以增量區塊的形式傳送至用戶端,那麼 App Engine 並不支援此類資料的串流回應。系統會依上述方式收集所有來自程式碼的資料,並做為單一 HTTP 回應傳送。

回應壓縮

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

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

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

指定要求期限

要求處理常式通常要在大約 60 秒的時間限制內對要求產生並傳回回應。期限一到,要求處理常式就會中斷。Python 執行階段環境會引發 DeadlineExceededError (來自 google.appengine.runtime 套件) 以中斷要求處理常式。如果要求處理常式沒有接收此例外狀況,則執行階段環境會將 HTTP 500 伺服器錯誤傳回至用戶端,就像處理所有未接收的例外狀況一樣。

要求處理常式可以接收此錯誤以自訂回應。執行階段環境會在引發例外狀況之後,多給要求處理常式一點時間 (少於 1 秒) 準備自訂的回應。

class TimerHandler(webapp2.RequestHandler):
    def get(self):
        from google.appengine.runtime import DeadlineExceededError

        try:
            time.sleep(70)
            self.response.write('Completed.')
        except DeadlineExceededError:
            self.response.clear()
            self.response.set_status(500)
            self.response.out.write(
                'The request did not complete in time.')

如果處理常式未傳回回應,或是在第二次到期時間時引發例外狀況,則處理常式會終止,而且系統會傳回預設的錯誤回應。

雖然要求的回應時間最長可達 60 秒,然而 App Engine 也對某些時間短暫的要求 - 尤其是只能有幾百毫秒的要求的應用程式進行最佳化。效率良好的應用程式能快速回應大部分的要求,至於回應速度不夠快的應用程式,則無法隨著 App Engine 的基礎架構妥善調度資源。

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

記錄

App Engine 網路伺服器會擷取處理常式指令碼寫入標準輸出串流的所有內容,以回應網路要求,還會擷取處理常式指令碼寫入標準錯誤串流的所有內容,並儲存為記錄資料。每項要求都會經由指派獲得 request_id;這是根據要求開始時間所指派的全域不重複 ID。在 GCP 主控台中,您可以使用 Stackdriver Logging 查看應用程式的記錄檔資料。

App Engine Python 執行階段特別支援包含來自 Python 標準程式庫的登入模組,以瞭解等登入層級 (「偵錯」、「資訊」、「警告」、「錯誤」、「重要」) 等登入概念。

import logging

import webapp2

class MainPage(webapp2.RequestHandler):
    def get(self):
        logging.debug('This is a debug message')
        logging.info('This is an info message')
        logging.warning('This is a warning message')
        logging.error('This is an error message')
        logging.critical('This is a critical message')

        try:
            raise ValueError('This is a sample value error.')
        except ValueError:
            logging.exception('A example exception log.')

        self.response.out.write('Logging example.')

app = webapp2.WSGIApplication([
    ('/', MainPage)
], debug=True)

環境

執行環境自動設定數個環境變數;您可以在 app.yaml 設定更多。在自動設定的變數中,有些是 App Engine 的特殊變數,而其他變數則是 WSGI 或 CGI 標準的一部分。Python 程式碼可使用 os.environ 字典存取這些變數。

下列環境變數專屬於 App Engine:

  • CURRENT_VERSION_ID:目前執行應用程式的主要和次要版本,例如「X.Y」。主要版本編號 (「X」) 是在應用程式的 app.yaml 檔案中指定。當每個版本的應用程式上傳到 App Engine 時,則會自動設定次要版本編號 (「Y」)。在開發網路伺服器上,次要版本一律是「1」。

  • AUTH_DOMAIN:用於使用 Users API 對使用者進行身分驗證的網域。appspot.com 託管的應用程式擁有 gmail.comAUTH_DOMAIN,並接受任何 Google 帳戶。自訂網域託管的應用程式擁有等同自訂網域的 AUTH_DOMAIN

  • INSTANCE_ID:包含處理要求的前端執行個體的 ID。ID 是十六進位字串 (例如 00c61b117c7f7fd0ce9e1325a04b8f0df30deaaf)。已登入的管理員可以使用網址中的 ID:http://[INSTANCE_ID].myApp.appspot.com/。要求將轉送到特定前端執行個體。假如執行個體無法處理要求,則立即傳回 503。

下列環境變數是 WSGI 和 CGI 標準的一部分,在 App Engine 中會有特殊行為:

  • SERVER_SOFTWARE:在開發網路伺服器中,此值為「Development/X.Y」,其中「X.Y」是執行階段的版本。在 App Engine 上運行時,這個值為「Google App Engine/X.Y.Z」。

系統會根據 WSGI 或 CGI 標準設定其他環境變數:如要進一步瞭解這些變數,請視需要參閱 WSGI 標準CGI 標準

您也可以在 app.yaml 檔案中設定環境變數:

env_variables:
  DJANGO_SETTINGS_MODULE: 'myapp.settings'

下列 webapp2 要求處理常式會顯示瀏覽器中應用程式可見的每個環境變數:

class PrintEnvironmentHandler(webapp2.RequestHandler):
    def get(self):
        self.response.headers['Content-Type'] = 'text/plain'
        for key, value in os.environ.iteritems():
            self.response.out.write(
                "{} = {}\n".format(key, value))

要求 ID

您可以在提出要求時保留要求 ID,這是該要求的專屬編號。之後可以在 Stackdriver Logging 中將要求 ID 用來查詢該要求的記錄。

以下範例程式碼顯示如何在要求的內文中取得要求 ID:

class RequestIdHandler(webapp2.RequestHandler):
    def get(self):
        self.response.headers['Content-Type'] = 'text/plain'
        request_id = os.environ.get('REQUEST_LOG_ID')
        self.response.write(
            'REQUEST_LOG_ID={}'.format(request_id))

應用程式快取

Python Runtime Environment 會在要求之間將匯入的模組快取於單一的網路伺服器,這種做法類似於在獨立的 Python 應用程式中,即使某個模組會由多個檔案匯入,該應用程式也只載入該模組一次。由於 WSGI 處理常式是模組,因此可以在要求之間進行快取。CGI 處理常式指令碼只有在提供 main() 日常程序時可供快取;否則,CGI 處理常式指令碼會針對每個要求載入。

應用程式快取可大幅縮短回應時間。我們建議所有 CGI 處理常式指令碼使用如上述的 main() 日常程序。

快取匯入

為了提高效率,網路伺服器會將匯入的模組存放在記憶體中,而且不會在相同的伺服器上,為針對相同應用程式所提出的後續要求重新載入或重新評估這些模組。大多數的模組在匯入時不會初始化任何全域資料,或是產生其他的副作用,因此快取這些模組不會變更應用程式的行為。

如果應用程式是根據每次要求所評估的模組來匯入模組,則應用程式必須配合此快取行為。

快取 CGI 處理常式

除了匯入的模組,您可要求 App Engine 對 CGI 處理常式指令碼本身進行快取。假如處理常式指令碼定義名為 main() 的函式,那麼指令碼及其全域環境將如同匯入的模組一樣進行快取。在指定的網路伺服器上第一次要求指令碼時,App Engine 會正常地評估該指令碼,針對後續要求,App Engine 會呼叫快取環境中的 main() 函式。

如要快取處理常式指令碼,App Engine 必須能夠呼叫不含引數的 main()。如果處理常式指令碼未定義 main() 函式,或 main() 函式需要引數 (沒有預設內容),則 App Engine 會針對每個要求載入和評估整個指令碼。

將剖析的 Python 程式碼儲存在記憶體可節省時間,並且獲得更快速的回應。您也可將全域環境存入快取,以提供其他用途:

  • 編譯的規則運算式:所有的規則運算式都會被剖析,並以編譯過的格式儲存。您可以將編譯的規則運算式儲存在全域變數中,然後在要求之間使用應用程式快取,以重複使用編譯過的物件。

  • GqlQuery 物件。建立 GqlQuery 物件時,系統會剖析 GQL 查詢字串。重新使用包含參數繫結的 GqlQuery 物件與 bind() 方法會比每次都重新構造物件更快。您可以將 GqlQuery 物件與值的參數繫結儲存在全域變數中,然後為每個要求繫結新的參數值來重複使用。

  • 設定和資料檔案:如果您的應用程式從檔案載入並剖析設定資料,程式可以將剖析的資料保留在記憶體中,以避免在每次要求時重新載入檔案。

處理常式指令碼必須在匯入時呼叫 main()。App Engine 預期匯入處理常式指令碼會呼叫 main(),如此 App Engine 在伺服器上首次載入要求處理常式時就不用呼叫它。

使用 main() 的應用程式快取可大幅縮短 CGI 處理常式的回應時間。我們建議所有使用 CGI 的應用程式採用這個方法。

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

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

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