ID regione
REGION_ID
è un codice abbreviato assegnato da Google
in base alla regione selezionata al momento della creazione dell'app. Il codice non
corrispondono a un paese o a una provincia, anche se potrebbero essere visualizzati alcuni ID regione
in modo simile ai codici paese e provincia di uso comune. Per le app create dopo il giorno
Febbraio 2020, REGION_ID.r
è incluso in
URL di App Engine. Per le app esistenti create prima di questa data,
l'ID regione è facoltativo nell'URL.
Scopri di più sugli ID regione.
Questo documento descrive come l'applicazione App Engine riceve richieste e invia risposte.
Per ulteriori dettagli, consulta l'articolo Riferimento a intestazioni e risposte delle richieste.
Se la tua applicazione utilizza servizi, puoi indirizzare le richieste a un servizio specifico o a una versione specifica completamente gestito di Google Cloud. Per ulteriori informazioni sull'indirizzabilità del servizio, vedi Come vengono le richieste Routed.
Gestione delle richieste
L'applicazione è responsabile dell'avvio di un server web e della gestione delle richieste. Puoi utilizzare qualsiasi framework web disponibile per il linguaggio di sviluppo.
App Engine esegue più istanze dell'applicazione e ogni
dispone del proprio server web per la gestione delle richieste. Qualsiasi richiesta può essere instradata
a qualsiasi istanza, quindi le richieste consecutive dello stesso utente non sono necessariamente
inviati alla stessa istanza. Un'istanza può gestire più richieste
contemporaneamente. Il numero di istanze può essere regolato automaticamente come traffico
modifiche.
Puoi anche modificare il numero di richieste in parallelo che un'istanza può gestire
impostando la classe max_concurrent_requests
nel file app.yaml.
app.yaml
dell'applicazione
di configurazione del deployment. Il runtime Python 2.7 supporta il protocollo WSGI
standard e il CGI
standard per
la compatibilità con le versioni precedenti. È preferibile utilizzare WSGI, e alcune funzionalità di Python 2.7 lo consentono
non funzionerà senza. La configurazione dello script dell'applicazione
Gestori
determina se una richiesta viene gestita tramite WSGI o CGI.
Il seguente script Python risponde a una richiesta con un'intestazione HTTP e
messaggio Hello, World!
.
Per inviare in parallelo più richieste a ciascun server web, contrassegna
come threadsafe aggiungendo un'etichetta
threadsafe: true
al tuo file app.yaml
. Le richieste in parallelo non sono disponibili se esistono script
usa CGI.
Quote e limiti
App Engine alloca automaticamente le risorse all'applicazione aumenta il traffico. Tuttavia, ciò è vincolato dalle seguenti restrizioni:
App Engine prenota la capacità di scalabilità automatica per le applicazioni bassa latenza, dove l'applicazione risponde alle richieste in meno di un secondo.
Le applicazioni che sono fortemente legate alla CPU possono inoltre subire una latenza aggiuntiva al fine di condividere in modo efficiente le risorse con altre applicazioni sulla stessa server web. Le richieste di file statici sono esenti da questi limiti di latenza.
Ogni richiesta in arrivo per l'applicazione viene conteggiata ai fini del limite di Richieste. I dati inviati in risposta a una richiesta vengono conteggiati ai fini del Limite Larghezza di banda in uscita (fatturabile).
Sia le richieste HTTP che quelle HTTPS (protette) vengono conteggiate ai fini delle Richieste, delle Richieste in entrata Limiti di larghezza di banda (fatturabile) e larghezza di banda in uscita (fatturabile). La Console Google Cloud Pagina Dettagli quota segnala anche Richieste sicure, Larghezza di banda in entrata sicura e Larghezza di banda in uscita sicura come valori separati a scopo informativo. Solo le richieste HTTPS vengono conteggiate per questi valori. Per ulteriori informazioni, consulta Quote.
I seguenti limiti si applicano nello specifico all'uso dei gestori delle richieste:
Limite | Quantità |
---|---|
Dimensioni richiesta | 32 megabyte |
Dimensione della risposta | 32 megabyte |
Timeout richiesta | Dipende dal tipo di scalabilità usata dall'app |
Numero totale massimo di file (file di app e file statici) | 10.000 in totale 1000 per directory |
Dimensione massima del file di un'applicazione | 32 megabyte |
Dimensione massima di un file statico | 32 megabyte |
Dimensione totale massima di tutti i file statici e dell'applicazione | Il primo gigabyte è gratuito $ 0,026 per gigabyte al mese dopo il primo gigabyte |
Timeout richiesta in attesa | 10 secondi |
Dimensione massima di un campo di intestazione della richiesta singola | 8 kilobyte per runtime di seconda generazione nell'ambiente standard. Le richieste a questi runtime con campi di intestazione che superano gli 8 kilobyte restituiranno errori HTTP 400. |
Limiti per le richieste
Tutte le richieste HTTP/2 verranno tradotte in richieste HTTP/1.1 quando inoltrate a al server delle applicazioni.
Limiti di risposta
Le risposte dinamiche sono limitate a 32 MB. Se un gestore di script genera una risposta oltre questo limite, il server restituisce una risposta vuota con un codice Codice di stato di errore interno del server. Questo limite non si applica alle risposte che forniscono dati nell'archivio BLOB legacy Cloud Storage.
Il limite per l'intestazione della risposta è 8 kB per i runtime di seconda generazione. Le intestazioni delle risposte che superano questo limite restituiranno errori HTTP 502, con log che mostrano
upstream sent too big header while reading response header from upstream
.
Intestazioni delle richieste
Una richiesta HTTP in entrata include le intestazioni HTTP inviate dal client. Per per motivi di sicurezza, alcune intestazioni vengono trattate o modificate da proxy intermedi prima di raggiungere l'applicazione.
Per ulteriori informazioni, consulta Riferimento alle intestazioni delle richieste.
Gestione dei timeout delle richieste
App Engine è ottimizzato per applicazioni con richieste di breve durata, di solito quelle che impiegano qualche centinaio di millisecondi. Un'app efficiente risponde per la maggior parte delle richieste. Un'app che non si adatta bene alla scalabilità con l'infrastruttura di App Engine. Per garantire questo livello di prestazioni, esiste una richiesta massima impostata dal sistema timeout a cui ogni app deve rispondere.
Se la tua app supera questa scadenza, App Engine interrompe il gestore delle richieste. L'ambiente di runtime Python porta a questo scopo aumentando EccezioneDeadlineExceededError
da google.appengine.runtime
. Se
gestore di richieste non rileva questa eccezione, come in tutte le eccezioni non rilevate,
l'ambiente di runtime restituirà al client un errore HTTP 500 del server.
Il gestore delle richieste può rilevare questo errore per personalizzare la risposta. Il runtime lascia al gestore delle richieste un po' più di tempo (meno di un il secondo) dopo aver sollevato l'eccezione per preparare una risposta personalizzata.
Se il gestore non ha restituito una risposta o sollevato un'eccezione al secondo scadenza, il gestore viene arrestato e viene restituita una risposta di errore predefinita.
Risposte
App Engine chiama lo script del gestore conRequest
e attende lo script
script da restituire; tutti i dati scritti nel flusso di output standard vengono inviati come
Risposta HTTP.
Esistono limiti di dimensioni che si applicano alle risposte genera e la risposta può essere modificata prima di essere restituita al client.
Per ulteriori informazioni, consulta la sezione Riferimento alle richieste di risposte.Risposte dinamiche
App Engine non supporta le risposte in modalità flusso quando i dati vengono inviati di chunk incrementali al client durante l'elaborazione di una richiesta. Tutti i dati dal codice vengono raccolti come descritto sopra e inviati come un unico HTTP risposta.
Compressione delle risposte
App Engine fa del suo meglio per pubblicare contenuti compressi (gzip) client che la supportano. Per determinare se i contenuti devono essere compressi, Quando riceve una richiesta, App Engine esegue le seguenti operazioni:Verifica se il client può ricevere in modo affidabile risposte compresse visualizzando entrambe le intestazioni
Accept-Encoding
eUser-Agent
della richiesta. Questo evita alcuni bug noti con contenuti compressi in formato gzip nei browser più diffusi.Per confermare che la compressione dei contenuti è appropriata, visualizza il Intestazione
Content-Type
che hai configurato per il di gestione delle risposte. In generale, la compressione è appropriata per i tipi di contenuti basati su testo e non per i tipi di contenuti binari.
Tieni presente quanto segue:
Un client può forzare la compressione dei tipi di contenuti basati su testo impostando sia delle intestazioni della richiesta
Accept-Encoding
eUser-Agent
agzip
.Se per una richiesta non è specificato
gzip
nell'intestazioneAccept-Encoding
, App Engine non comprime i dati di risposta.Google Frontend memorizza nella cache le risposte del file statico di App Engine e gestori di directory. In base a una serie di fattori, come il tipo di i dati delle risposte vengono prima memorizzati nella cache. Le intestazioni
Vary
che hai specificato e quali intestazioni sono incluse nella richiesta, un client potrebbe richiedere che però ricevono dati non compressi e viceversa. Per Per ulteriori informazioni, consulta Memorizzazione nella cache delle risposte.
Memorizzazione nella cache delle risposte
Il frontend Google e potenzialmente il browser dell'utente e altri utenti intermedi di memorizzazione nella cache dei server proxy, memorizzerà nella cache le risposte della tua app come indicato intestazioni standard per la memorizzazione nella cache specificate nella risposta. Puoi specificare queste intestazioni di risposta attraverso il tuo framework, direttamente o mediante il file statico e la directory di App Engine e i gestori di rete.
In Google Frontend, la chiave cache è l'URL completo della richiesta.
Memorizzazione nella cache di contenuti statici
Per garantire che i clienti ricevano sempre i contenuti statici aggiornati non appena possibile.
pubblicata, ti consigliamo di pubblicare contenuti statici
come css/v1/styles.css
. Google Frontend non eseguirà la convalida
nella cache (verifica la presenza di contenuti aggiornati) fino alla scadenza. Anche dopo
scadono, la cache non viene aggiornata finché i contenuti non vengono
Modifiche agli URL.
Le seguenti intestazioni di risposta che puoi
impostato in
app.yaml
influenzano come e quando Google Frontend memorizza i contenuti nella cache:
Cache-Control
deve essere impostato supublic
affinché Google Frontend possa memorizzare nella cache contenuti; potrebbe anche essere memorizzata nella cache da Google Frontend a meno che non specifichi IstruzioneCache-Control
private
ono-store
. Se non la imposti intestazione inapp.yaml
, App Engine lo aggiunge automaticamente per tutti risposte gestite da un file statico o da un gestore di directory. Per ulteriori informazioni informazioni, consulta la sezione Intestazioni aggiunte o sostituite.Vary
: per consentire alla cache di restituire risposte diverse per un URL in base a inviate nella richiesta, impostare uno o più dei seguenti valori nell'intestazione della rispostaVary
:Accept
,Accept-Encoding
,Origin
oX-Origin
Data la potenziale cardinalità elevata, i dati non verranno memorizzati nella cache
Vary
valori.Ad esempio:
Specifica la seguente intestazione della risposta:
Vary: Accept-Encoding
La tua app riceve una richiesta contenente l'intestazione
Accept-Encoding: gzip
. App Engine restituisce una risposta compressa e Google Frontend memorizza nella cache la versione compressa con gzip dei dati di risposta. Tutte le richieste successive per questo URL che contiene l'intestazioneAccept-Encoding: gzip
riceverà i dati compressi con gzip dalla cache fino all'invalidazione della cache (a causa i contenuti che cambiano dopo la scadenza della cache).La tua app riceve una richiesta che non contiene
Accept-Encoding
intestazione. App Engine restituisce una risposta non compressa e Google Il frontend memorizza nella cache la versione non compressa dei dati della risposta. Tutti i successivi richieste per questo URL che non contengono l'intestazioneAccept-Encoding
riceverà i dati compressi dalla cache fino a quando invalidato.
Se non specifichi un'intestazione della risposta
Vary
, Google Frontend crea singola voce della cache per l'URL e la utilizzerà per tutte le richieste delle intestazioni nella richiesta. Ad esempio:- Non devi specificare l'intestazione della risposta
Vary: Accept-Encoding
. - Una richiesta contiene l'intestazione
Accept-Encoding: gzip
e il file dei dati della risposta verrà memorizzata nella cache. - Una seconda richiesta non contiene l'intestazione
Accept-Encoding: gzip
. Tuttavia, poiché la cache contiene una versione compressa con gzip dei dati della risposta, la risposta verrà compressa in formato gzip anche se il client ha richiesto e i dati di Google Cloud.
Anche le intestazioni della richiesta influiscono sulla memorizzazione nella cache:
- Se la richiesta contiene un'intestazione
Authorization
, i contenuti non saranno memorizzati nella cache da Google Frontend.
Scadenza cache
Per impostazione predefinita, le intestazioni di memorizzazione nella cache del file statico di App Engine i gestori di directory aggiungono alle risposte indicano a client e proxy web come Google Frontend farà scadere la cache dopo 10 minuti.
Dopo che un file viene trasmesso con una data di scadenza, in genere c'è non c'è modo di svuotarle dalle cache dei proxy web, anche se l'utente cancella i propri della propria cache del browser. Il nuovo deployment di una nuova versione dell'app non reimposterà nessuna . Pertanto, se prevedi di modificare un file statico, questo dovrebbe avere un scadenza breve (meno di un'ora). Nella maggior parte dei casi, l'impostazione predefinita di 10 minuti data di scadenza sia appropriata.
Puoi modificare la scadenza predefinita per tutti i gestori di file e directory statici
specificando
default_expiration
in
app.yaml
. Per impostare tempi di scadenza specifici per
e i gestori di rete,
specificare expiration
all'interno dell'elemento gestore
app.yaml
.
Il valore specificato negli elementi di scadenza time verrà utilizzato
imposta le intestazioni della risposta HTTP Cache-Control
e Expires
.
Memorizzazione nella cache dell'app
L'ambiente di runtime Python memorizza nella cache i moduli importati tra le richieste su un un singolo server web, in modo simile al caricamento di un modulo da parte di un'applicazione Python autonoma solo una volta anche se il modulo è importato da più file. Poiché i gestori WSGI sono moduli, vengono memorizzati nella cache tra le richieste. Gli script del gestore CGI memorizzati nella cache se forniscono una routinemain()
; altrimenti lo script del gestore CGI
per ogni richiesta.
La memorizzazione nella cache delle app offre un vantaggio significativo in termini di tempo di risposta. È consigliabile tutti gli script dei gestori CGI usano una routine main(), come descritto di seguito.
Le importazioni vengono memorizzate nella cache
Per maggiore efficienza, il server web mantiene i moduli importati in memoria e non memorizza caricarle o rivalutarle nelle richieste successive alla stessa applicazione sul sullo stesso server. La maggior parte dei moduli non inizializza dati globali o non ha un altro lato effetti al momento dell'importazione, quindi memorizzarle nella cache non cambia il comportamento per l'applicazione.
Se la tua applicazione importa un modulo che dipende da quello valutato per ogni richiesta, l'applicazione deve soddisfare questo comportamento di memorizzazione nella cache.
Memorizzazione nella cache dei gestori CGI
Puoi indicare ad App Engine di memorizzare nella cache lo script del gestore CGI stesso,
oltre ai moduli importati. Se lo script del gestore definisce una funzione denominata
main()
, lo script e il suo ambiente globale verranno memorizzati nella cache come
modulo importato. La prima richiesta dello script su un determinato server web
valuta lo script normalmente. Per le richieste successive, App Engine chiama
la funzione main()
nell'ambiente memorizzato nella cache.
Per memorizzare nella cache uno script gestore, App Engine deve essere in grado di chiamare main()
con
senza argomenti. Se lo script del gestore non definisce una funzione main()
, oppure lo script
La funzione main()
richiede argomenti (che non hanno valori predefiniti), quindi
App Engine carica e valuta l'intero script per ogni richiesta.
Conservare il codice Python analizzato consente di risparmiare tempo e velocizzare diverse. La memorizzazione nella cache dell'ambiente globale ha anche altri potenziali usi:
Espressioni regolari compilate. Tutte le espressioni regolari vengono analizzate e archiviate in un modulo compilato. Puoi archiviare le espressioni regolari compilate in , quindi utilizza la memorizzazione nella cache dell'app per riutilizzare gli oggetti compilati tra richieste.
GqlQuery. La stringa di query GQL viene analizzata al momento della creazione dell'oggetto GqlQuery. Riutilizzo di un Oggetto GqlQuery con associazione di parametri e bind() è più veloce della ricostruzione ogni volta dell'oggetto. Puoi memorizzare un Oggetto GqlQuery con associazione di parametri per i valori in una variabile globale. e riutilizzarlo associando nuovi valori parametro per ogni richiesta.
File di configurazione e di dati. Se la tua applicazione carica e analizza di configurazione di un file, può conservare i dati analizzati in memoria evitando di ricaricare il file a ogni richiesta.
Lo script del gestore deve chiamare main()
al momento dell'importazione. App Engine
prevede che l'importazione dello script chiami main()
, quindi App Engine non
quando carichi il gestore di richieste per la prima volta su un server.
La memorizzazione nella cache dell'app con main()
fornisce un miglioramento significativo nella tua CGI
il tempo di risposta del gestore. Lo consigliamo per tutte le applicazioni che utilizzano CGI.
Logging
Il server web di App Engine acquisisce tutto ciò che scrive lo script del gestore al flusso di output standard per la risposta alla richiesta web. Inoltre, acquisisce tutto ciò che lo script del gestore scrive nel flusso di errori standard e e li archivia come dati di log. A ogni richiesta viene assegnato unrequest_id
,
un identificatore univoco globale basato sull'ora di inizio della richiesta. Dati dei log per
dell'applicazione può essere visualizzata nella console Google Cloud
utilizzando Cloud Logging.
L'ambiente di runtime Python di App Engine include un supporto speciale per il modulo di logging dalla libreria standard Python per comprendere i concetti di logging come livelli ("debug", "info", "warning", "error", "critical").
Ambiente
L'ambiente di esecuzione imposta automaticamente diverse variabili di ambiente; tu puoi impostare altre opzioni inapp.yaml
. Tra le variabili impostate automaticamente, alcune sono speciali
ad App Engine, mentre altri fanno parte degli standard WSGI o CGI. Codice Python
può accedere a queste variabili utilizzando il dizionario os.environ
.
Le seguenti variabili di ambiente sono specifiche di App Engine:
CURRENT_VERSION_ID
: la versione principale e secondaria dell'interfaccia attualmente in esecuzione dell'applicazione, come "X.Y". Il numero di versione principale ("X") è specificato nellaapp.yaml
. Il numero di versione secondario ("Y") viene impostato automaticamente quando dell'app in App Engine. Sul web per lo sviluppo server, la versione secondaria è sempre "1".AUTH_DOMAIN
: il dominio utilizzato per autenticare gli utenti con l'API Users. Le app ospitate su appspot.com hanno un valoreAUTH_DOMAIN
digmail.com
e accettano qualsiasi Account Google Le app ospitate su un dominio personalizzato hanno un valoreAUTH_DOMAIN
uguale a il dominio personalizzato.INSTANCE_ID
: contiene l'ID istanza dell'istanza di frontend che gestisce una richiesta. L'ID è una stringa esadecimale (ad esempio,00c61b117c7f7fd0ce9e1325a04b8f0df30deaaf
). Un amministratore che ha eseguito l'accesso può utilizzare l'ID in un URL:https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
. La richiesta verrà indirizzata a quella specifica istanza di frontend. Se l'istanza non può gestire la richiesta, restituisce immediatamente un errore 503.
Le seguenti variabili di ambiente fanno parte degli standard WSGI e CGI, con un comportamento speciale in App Engine:
SERVER_SOFTWARE
: nel server web di sviluppo, questo valore è "Sviluppo/X.Y" dove "X.Y" è la versione del runtime. Durante l'esecuzione nell'app Engine, questo valore è "Google App Engine/X.Y.Z".
Ulteriori variabili di ambiente vengono impostate secondo lo standard WSGI o CGI. Per ulteriori informazioni su queste variabili, consulta il Centro standard o CGI standard, a seconda dei casi.
Puoi anche impostare le variabili di ambiente nella app.yaml
file:
env_variables:
DJANGO_SETTINGS_MODULE: 'myapp.settings'
Il seguente gestore di richieste webapp2 mostra ogni variabile di ambiente visibile all'applicazione nel browser:
ID richieste
Al momento della richiesta, puoi salvare l'ID richiesta, che è univoco richiesta. L'ID richiesta può essere utilizzato in un secondo momento per cercare i log per quella richiesta in Cloud Logging.
Il seguente codice campione mostra come ottenere l'ID richiesta nel contesto di una richiesta:
Forzare le connessioni HTTPS
Per motivi di sicurezza, tutte le applicazioni devono incoraggiare i client a connettersi
https
. Per indicare al browser di preferire https
rispetto a http
per una determinata pagina
o un intero dominio, imposta l'intestazione Strict-Transport-Security
nelle risposte.
Ad esempio:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Per impostare questa intestazione per eventuali contenuti statici pubblicati dalla tua app, aggiungi l'elemento
l'intestazione al file statico e alla directory dell'app
e i gestori.
Per impostare questa intestazione per le risposte generate dal codice, utilizza il metodo
Raccolta flask-talisman
.
Gestione asincroni in background
Per lavoro in background si intende qualsiasi lavoro eseguito dall'app per una richiesta dopo che hai fornito la tua risposta HTTP. Evita di eseguire lavori in background nell'app. Rivedi il codice per assicurarti che tutte le operazioni asincrone siano completate prima di la tua risposta.
Per i job a lunga esecuzione, consigliamo di utilizzare Cloud Tasks. Con Cloud Tasks, le richieste HTTP hanno una lunga durata e restituiscono solo una risposta al termine del lavoro asincrono.