Modalità di gestione delle richieste

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 febbraio 2020, REGION_ID.r è incluso negli 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 il modo in cui l'applicazione App Engine riceve richieste e invia risposte.

Per maggiori dettagli, consulta la documentazione di riferimento su intestazioni di richiesta e risposte.

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 tuo linguaggio di sviluppo.

App Engine esegue più istanze della tua applicazione e ogni istanza ha il proprio server web per gestire le richieste. Qualsiasi richiesta può essere indirizzata a qualsiasi istanza, pertanto le richieste consecutive dello stesso utente non vengono necessariamente inviate 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.

Il server determina quale script di gestore PHP eseguire confrontando l'URL della richiesta con i pattern URL nel file di configurazione app.yaml dell'app. Quindi esegue lo script compilato con i dati della richiesta. La il server web inserisce i dati della richiesta in variabili di ambiente e flusso di dati. Lo script esegue le azioni appropriate per la richiesta, quindi prepara una e la inserisce nel flusso di output standard.

L'esempio seguente è uno script PHP che risponde a qualsiasi richiesta HTTP con il messaggio "Hello World!"

<?php

echo 'Hello, World!';

Quote e limiti

App Engine alloca automaticamente le risorse all'applicazione aumenta il traffico. Tuttavia, ciò è vincolato dalle seguenti restrizioni:

  • App Engine riserva la capacità di scalabilità automatica per le applicazioni con una bassa latenza, in cui l'applicazione risponde alle richieste in meno di un secondo.

  • Le applicazioni che richiedono un'elevata elaborazione della CPU potrebbero anche presentare una latenza aggiuntiva per condividere in modo efficiente le risorse con altre applicazioni sugli stessi server. Le richieste di file statici sono esenti da questi limiti di latenza.

Ogni richiesta in arrivo all'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 (sicure) vengono conteggiate ai fini dei limiti di Richieste, Larghezza di banda in entrata (fatturabile) e Larghezza di banda in uscita (fatturabile). La pagina dei dettagli delle quote della console Google Cloud riporta 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 specificamente all'utilizzo dei gestori delle richieste:

Limite Quantità
Dimensioni richiesta 32 megabyte
Dimensione della risposta 32 megabyte
Timeout richiesta Dipende dal tipo di scalabilità utilizzato dalla tua 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 della richiesta in attesa 10 secondi
Dimensione massima di un singolo campo dell'intestazione della richiesta 8 kilobyte per i runtime di seconda generazione nell'ambiente standard. Le richieste a questi runtime con campi di intestazione superiori a 8 kilobyte restituiranno errori HTTP 400.

Limiti per le richieste

Tutte le richieste HTTP/2 verranno tradotte in richieste HTTP/1.1 quando vengono inoltrate al server dell'applicazione.

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 valore Codice di stato di errore interno del server. Questa limitazione non si applica alle risposte che pubblicano dati provenienti da Cloud Storage.

  • Il limite di intestazione di 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 arrivo include le intestazioni HTTP inviate dal client. Per per motivi di sicurezza, alcune intestazioni vengono convalidate 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 le applicazioni con richieste di breve durata, tipicamente quelle che richiedono alcune centinaia di millisecondi. Un'app efficiente risponde per la maggior parte delle richieste. Un'app che non lo fa non avrà una buona 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 uno script PHP supera questa scadenza, il bit TIMEOUT sulla connessione campo di bit stato è impostata. Lo script avrà quindi una seconda scadenza breve per ripulire eventuali attività in esecuzione prolungata e restituire una risposta all'utente.

Se lo script non ha restituito una risposta entro la seconda scadenza, il gestore viene interrotto e viene restituita una risposta di errore predefinita.

Risposte

App Engine chiama lo script con l'array $_REQUEST compilato, memorizza nel buffer qualsiasi output dello script e, quando lo script completa l'esecuzione, invia l'output presente nel buffer all'utente finale.

Esistono limiti di dimensione che si applicano alla risposta generata e la risposta può essere modificata prima di essere restituita al client.

Per ulteriori informazioni, consulta la sezione Documentazione di riferimento per le risposte alle richieste.

Risposte dinamiche

App Engine non supporta le risposte in streaming in cui i dati vengono inviati al client in blocchi incrementali durante l'elaborazione di una richiesta. Tutti i dati del codice vengono raccolti come descritto sopra e inviati come singola risposta HTTP.

Compressione delle risposte

App Engine fa del suo meglio per pubblicare contenuti compressi (con gzip) per i client che li supportano. Per determinare se i contenuti devono essere compressi, Quando riceve una richiesta, App Engine esegue le seguenti operazioni:

  1. Verifica se il client può ricevere in modo affidabile le risposte compresse visualizzando entrambe le intestazioni Accept-Encoding e User-Agent nella richiesta. Questo evita alcuni bug noti con contenuti compressi in formato gzip nei browser più diffusi.

  2. Verifica se la compressione dei contenuti è appropriata visualizzando l'Content-Type header che hai configurato per il gestore della risposta. 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 e User-Agent a gzip.

  • Se per una richiesta non è specificato gzip nell'intestazione Accept-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. A seconda di una serie di fattori, ad esempio il tipo di dati della risposta memorizzati nella cache per primo, le intestazioni Vary che hai specificato nella risposta e le intestazioni incluse nella richiesta, un client potrebbe richiedere dati compressi, ma ricevere 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 tramite il tuo framework, direttamente nel codice o tramite gli handler di directory e file statici di App Engine.

In Google Frontend, la chiave della cache è l'URL completo della richiesta.

Memorizzazione nella cache di contenuti statici

Per assicurarti che i clienti ricevano sempre contenuti statici aggiornati non appena vengono pubblicati, ti consigliamo di pubblicarli da directory con versioni, ad esempio css/v1/styles.css. Il Frontend di Google non convalida la cache (controlla la presenza di contenuti aggiornati) fino alla scadenza della cache. Anche dopo scadono, la cache non viene aggiornata finché i contenuti non vengono Modifiche agli URL.

Le seguenti intestazioni di risposta che puoi impostare in app.yaml influiscono su come e quando il Frontend di Google memorizza nella cache i contenuti:

  • Cache-Control deve essere impostato su public affinché il frontend di Google memorizzi nella cache i contenuti. Potrebbe anche essere memorizzato nella cache dal frontend di Google, a meno che non specifichi un'istruzione Cache-Control private o no-store. Se non imposti questo header in app.yaml , App Engine lo aggiunge automaticamente per tutte le risposte gestite da un gestore di directory o file statico. Per ulteriori 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 risposta Vary: Accept, Accept-Encoding, Origin o X-Origin

    A causa della potenziale alta cardinalità, i dati non verranno memorizzati nella cache per altri valoriVary.

    Ad esempio:

    1. Specifica la seguente intestazione della risposta:

      Vary: Accept-Encoding

    2. 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'intestazione Accept-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).

    3. 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'intestazione Accept-Encoding riceverà i dati compressi dalla cache fino a quando invalidato.

    Se non specifichi un'intestazione di risposta Vary, il frontend di Google crea una singola voce della cache per l'URL e la utilizza per tutte le richieste, indipendentemente dalle intestazioni nella richiesta. Ad esempio:

    1. Non devi specificare l'intestazione della risposta Vary: Accept-Encoding.
    2. Una richiesta contiene l'intestazione Accept-Encoding: gzip e il file dei dati della risposta verrà memorizzata nella cache.
    3. 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 verranno memorizzati nella cache dal frontend di Google.

Scadenza della cache

Per impostazione predefinita, le intestazioni di memorizzazione nella cache aggiunte ai gestori di directory e file statici di App Engine alle risposte ordinano ai client e ai proxy web, come il frontend di Google, di 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, deve avere un breve periodo di scadenza (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 l'elemento default_expiration nel file 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 di PHP include OPcache che può memorizzare nella cache PHP il codice intermedio e migliorare significativamente il tempo di risposta della tua applicazione. Puoi disattivare la memorizzazione nella cache OPcache impostando opcache.enabled = "0" nel php.ini dell'applicazione .

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. I dati dei log per la tua applicazione possono essere visualizzati nella console Google Cloud utilizzando Cloud Logging.

L'ambiente di runtime PHP di App Engine include il supporto per la registrazione di messaggi arbitrari della tua applicazione utilizzando la funzione integrata di PHP syslog(), che richiama l'API Logs.

Ambiente

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 questo intestazione per tutti i contenuti statici pubblicati dalla tua app, aggiungila agli handler di file e directory statici della tua app.

Gestione asincroni in background

Il lavoro in background è qualsiasi lavoro eseguito dalla tua app per una richiesta dopo che hai fornito la risposta HTTP. Evita di eseguire lavori in background nell'app e rivedi il codice per assicurarti che tutte le operazioni asincrone vengano completate prima di la tua risposta.

Per i job di lunga durata, consigliamo di utilizzare Cloud Tasks. Con Cloud Tasks, le richieste HTTP sono di lunga durata e restituiscono una risposta solo al termine di qualsiasi lavoro asincrono.