Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
ID regione
REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata al momento della creazione dell'app. Non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono apparire simili ai codici di 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.
Puoi configurare le impostazioni dell'app App Engine nel file di configurazione app.yaml. Il file di configurazione deve specificare almeno una voce runtime.
Ogni servizio nella tua app ha il proprio file app.yaml, che funge da descrittore per il suo deployment. Devi creare il file app.yaml per il servizio default prima di poter creare ed eseguire il deployment di file app.yaml per servizi aggiuntivi all'interno dell'app. Per scoprire di più sulla strutturazione di più servizi nell'app, consulta Strutturare i servizi web in App Engine.
Il formato YAML supporta i commenti. Una riga che inizia con un carattere cancelletto (#) viene ignorata:
# This is a comment.
I pattern URL e di percorso file utilizzano la sintassi di espressioni regolari estese POSIX, escludendo gli elementi di confronto e le classi di confronto. Sono supportati i riferimenti a ritroso alle corrispondenze raggruppate (ad esempio \1), così come le seguenti estensioni Perl: \w \W \s \S \d \D.
Esempio
Di seguito è riportato un esempio di file app.yaml:
Elementi di runtime e app
Elemento
Descrizione
app_engine_apis
build_env_variables
Facoltativo. Se utilizzi un runtime che supporta buildpacks, puoi definire le variabili di ambiente di build nel tuo file app.yaml.
Facoltativo. Imposta un periodo predefinito globale per la cache per tutti i gestori di file statici di un'applicazione. Puoi anche configurare una durata della cache per specifici gestori di file
statici. Il valore è una stringa di numeri e unità, separati da spazi, in cui le unità possono essere d per i giorni, h per le ore, m per i minuti e s per i secondi. Ad esempio, "4d 5h" imposta la scadenza della cache su 4 giorni e 5 ore dopo la prima richiesta del file. Se omesso, il server di produzione imposta la scadenza su 10 minuti.
Facoltativo.
Puoi definire le variabili di ambiente nel file app.yaml
per renderle disponibili nella tua app. Assicurati che la chiave nelle variabili di ambiente corrisponda all'espressione '[a-zA-Z_][a-zA-Z0-9_]*' (inizia con l'alfabeto o "_" seguito da caratteri alfanumerici o "_").
Le variabili di ambiente con prefisso GAE sono riservate all'uso da parte del sistema e non sono consentite nel file app.yaml.
error_handlers
Facoltativo.
Utilizzato per configurare le pagine di errore personalizzate che vengono restituite per tipi di errore diversi.
Questo elemento può contenere i seguenti elementi:
error_code
Facoltativo. error_code può essere uno dei seguenti:
Pubblicata se viene raggiunta una scadenza prima che la tua app
riceva una risposta.
L'errore error_code è facoltativo; se non è specificato, il file fornito è la risposta di errore predefinita per la tua app.
file
Ogni voce di file indica un file statico che deve essere pubblicato al posto della risposta di errore generica. Se specifichi un elemento file senza un elemento error_code corrispondente, il file statico sarà la pagina di errore predefinita per la tua app.
I dati di errore personalizzati devono essere inferiori a 10 kilobyte.
Facoltativo.
Un elenco di pattern URL e descrizioni di come devono essere gestiti.
App Engine può gestire gli URL eseguendo il codice dell'applicazione o pubblicando file statici caricati con il codice, come immagini, CSS o JavaScript.
Facoltativo.
Le applicazioni devono abilitare questi servizi prima di poter ricevere le richieste in entrata. Puoi abilitare il servizio per un'app includendo una sezione inbound_services nel file app.yaml.
I seguenti valori sono disponibili in base alla scalabilità del servizio:
Scalabilità automatica
F1, F2, F4, F4_1G
Impostazioni predefinite:F1
Facoltativamente, utilizza l'elemento automatic_scaling per modificare le impostazioni
predefinite per la scalabilità automatica, come il numero minimo e massimo
di istanze, la latenza e le connessioni simultanee.
Nota: se il valore di instance_class è impostato su F2 o su un valore superiore, puoi ottimizzare le istanze impostando max_concurrent_requests su un valore superiore al valore predefinito di 10. Per determinare il valore ottimale, aumentalo gradualmente e monitora le prestazioni della tua applicazione.
Scalabilità di base e manuale
B1, B2, B4, B4_1G, B8
Predefinito:B2
Le classi di istanza di base e manuali richiedono di specificare
l'elemento basic_scaling o l'elemento manual_scaling.
main
Facoltativo.
Per Go, il percorso o il nome completo del pacchetto del pacchetto principale. Questa impostazione si applica solo se l'app utilizza la modalità Vai a modulo.
Devi dichiarare il percorso del pacchetto principale se
package main non si trova nella stessa directory del pacchetto
app.yaml. L'elemento main supporta i percorsi dei file relativi a app.yaml o i nomi completi dei pacchetti. Ad
esempio, se la tua app ha questa struttura di directory:
Obbligatorio. Il nome dell'ambiente di runtime utilizzato dall'app. Ad esempio, per specificare l'ambiente di runtime, utilizza:
service
Obbligatorio se stai creando un
servizio.
Facoltativo per il servizio default. Ogni servizio e ogni versione devono avere un nome. Un nome può contenere numeri, lettere e trattini. La lunghezza combinata di
VERSION-dot-SERVICE-dot-PROJECT_ID, dove VERSION è il nome della
versione, SERVICE è il nome del servizio e PROJECT_ID
è l'ID progetto, non può superare i 63 caratteri e non può
iniziare o terminare con un trattino. Scegli un nome univoco per ciascun servizio e ciascuna versione. Non riutilizzare i nomi tra servizi e versioni.
Esempio:
service: service-name
service_account
Facoltativo. L'elemento service_account consente di specificare un
account di servizio specifico della versione come identità per la versione. L'account di servizio specificato viene utilizzato per accedere ad altri servizi Google Cloud ed eseguire attività.
Facoltativo.
Configura la tua applicazione per utilizzare un connettore di accesso VPC serverless, consentendo all'applicazione di inviare richieste alle risorse interne nella tua rete VPC. Per maggiori informazioni, consulta
Connessione a una rete VPC.
name
Valore letterale stringa. Specifica il nome completo del
connettore di accesso VPC serverless tra virgolette:
Facoltativo. Il valore predefinito è private-ranges-only. egress_setting può essere uno dei seguenti:
private-ranges-only
Predefinita. Le richieste agli indirizzi IP interni vengono inviate tramite il connettore di accesso VPC serverless alla rete VPC connessa. Le richieste agli indirizzi IP esterni vengono inviate alla rete internet pubblica.
all-traffic
Tutte le richieste vengono inviate tramite il connettore di accesso VPC serverless alla rete VPC connessa.
L'elemento handlers fornisce un elenco di pattern URL e descrizioni di come devono essere gestiti. App Engine può gestire gli URL eseguendo il codice dell'applicazione o pubblicando file statici caricati con il codice, come immagini, CSS o JavaScript.
I pattern vengono valutati nell'ordine in cui appaiono nel file app.yaml, dall'alto verso il basso. La prima mappatura il cui pattern corrisponde all'URL è quella utilizzata per gestire la richiesta.
Nella tabella seguente sono elencati i sottoelementi dell'elemento handlers che controllano il comportamento di file statici, directory statiche, script in runtime diversi da Node.js e altre impostazioni.
Elemento
Descrizione
auth_fail_action
Per utilizzare questo elemento,
app_engine_apis deve essere impostato su true.
Facoltativo.
Descrive l'azione intrapresa quando l'elemento login è specificato per un gestore e l'utente non ha eseguito l'accesso. Ha due valori possibili:
redirect
Predefinito. L'utente viene reindirizzato alla pagina di accesso di Google o
a /_ah/login_required se viene utilizzata l'autenticazione OpenID.
L'utente viene reindirizzato all'URL dell'applicazione dopo aver eseguito l'accesso o aver creato un account.
unauthorized
La richiesta viene rifiutata con un codice di stato HTTP 401 e un messaggio di errore.
Se un'applicazione ha bisogno di un comportamento diverso, può implementare la gestione degli accessi degli utenti. Ad esempio, richiedendo l'accesso
per la directory /profile/ o come amministratore per
la directory /admin/. Per ulteriori informazioni, consulta l'API
Users.
Puoi configurare un gestore in modo che neghi l'accesso agli URL protetti quando l'utente non ha eseguito l'accesso, anziché reindirizzarlo alla pagina di accesso, aggiungendo auth_fail_action: unauthorized alla configurazione del gestore.
expiration
Facoltativo.
Il periodo di tempo in cui un file statico pubblicato da questo gestore deve essere memorizzato nella cache da proxy web e browser. Il valore è una stringa di numeri e unità, separati da spazi, dove le unità possono essere d per i giorni, h per le ore, m per i minuti e s per i secondi. Ad esempio, "4d 5h" imposta la scadenza della cache su 4 giorni e 5 ore dopo la prima richiesta del file. Se omesso, viene utilizzato il valore default_expiration dell'applicazione. Per ulteriori dettagli, consulta Scadenza della cache.
http_headers
Facoltativo. Puoi impostare intestazioni HTTP per le risposte dei gestori di directory o file statici.
Se devi impostare le intestazioni HTTP nei gestori script, dovrai farlo nel codice dell'app. Per informazioni su quali intestazioni di risposta influenzano la memorizzazione nella cache, consulta Memorizzazione nella cache di contenuti statici.
handlers:
- url: /images
static_dir: static/images
http_headers:
X-Foo-Header: foo
X-Bar-Header: bar value
vary: Accept-Encoding
# ...
Supporto CORS
Un uso importante di questa funzionalità è il supporto della condivisione delle risorse tra origini (CORS), ad esempio l'accesso ai file ospitati da un'altra app di App Engine.
Ad esempio, potresti avere un'app di gioco mygame.uc.r.appspot.com
che accede agli asset ospitati da myassets.uc.r.appspot.com.
Tuttavia, se mygame tenta di creare un codice JavaScript
XMLHttpRequest in myassets, non avrà esito positivo a meno che il gestore per myassets non restituisca un'intestazione della risposta Access-Control-Allow-Origin: contenente il valore http://mygame.uc.r.appspot.com.
Ecco come fare in modo che il gestore di file statico restituisca il valore richiesto per l'intestazione della risposta:
Suggerimento: per consentire a tutti di accedere ai tuoi asset, puoi utilizzare il carattere jolly '*', anziché https://mygame.uc.r.appspot.com.
login
Per utilizzare questo elemento,
app_engine_apis deve essere impostato su true.
Facoltativo.
Determina se il gestore di URL richiede che l'utente abbia eseguito l'accesso.
Questo elemento ha tre possibili valori:
optional
Predefinita. Non richiede che l'utente abbia eseguito l'accesso.
required
Se l'utente ha eseguito l'accesso, il gestore procede normalmente. In caso contrario,
viene eseguita l'azione specificata in auth_fail_action.
admin
Come con required, esegue auth_fail_action
se l'utente non ha eseguito l'accesso. Inoltre, se l'utente non è un amministratore dell'applicazione, viene visualizzato un messaggio di errore indipendentemente dall'impostazione auth_fail_action. Se l'utente è un amministratore, il gestore procede.
Quando un gestore di URL con un'impostazione login diversa da optional corrisponde a un URL, il gestore verifica innanzitutto se l'utente ha eseguito l'accesso all'applicazione utilizzando la propria
opzione di autenticazione. In caso contrario, per impostazione predefinita, l'utente viene reindirizzato alla pagina di accesso. Puoi anche utilizzare auth_fail_action per
configurare l'app in modo che rifiuti semplicemente le richieste di un gestore da parte di utenti
non correttamente autenticati, anziché reindirizzare l'utente alla
pagina di accesso.
Nota: la limitazione dell'accesso admin è soddisfatta anche per le richieste interne per le quali App Engine imposta le intestazioni speciali X-Appengine appropriate. Ad esempio, cron attività pianificate soddisfano la limitazione admin, perché App Engine imposta un'intestazione HTTP X-Appengine-Cron: true sulle rispettive richieste.
Tuttavia, le richieste non soddisfano la limitazione di accesso di required, perché le attività pianificate cron non vengono eseguite come nessun utente.
mime_type
Facoltativo. Se specificato, tutti i file pubblicati da questo gestore verranno pubblicati utilizzando il tipo MIME specificato. Se non specificato, il tipo MIME di un file verrà derivato dall'estensione del nome del file.
Se lo stesso file viene caricato con più estensioni, l'estensione risultante può dipendere dall'ordine in cui sono stati eseguiti i caricamenti.
Facoltativo. redirect_http_response_code viene utilizzato con l'impostazione secure per impostare il codice di risposta HTTP restituito quando si esegue un reindirizzamento richiesto in base alla configurazione dell'impostazione secure.
L'elemento redirect_http_response_code ha i seguenti
valori possibili:
301
Codice di risposta permanente spostato.
302
Codice di risposta trovato.
303
Vedi Altro codice di risposta.
307
Codice di risposta di reindirizzamento temporaneo.
Quando la richiesta di un utente viene reindirizzata, il codice di stato HTTP viene impostato sul valore del parametro redirect_http_response_code. Se il parametro non è presente, verrà restituito il valore 302.
script
Facoltativo.
Specifica che le richieste al gestore specifico devono avere come target la tua app. L'unico valore accettato per l'elemento script è auto perché tutto il traffico viene gestito utilizzando il comando del punto di ingresso. Per utilizzare gestori statici, almeno uno dei gestori deve contenere la riga script: auto o definire un elemento entrypoint affinché il deployment venga eseguito correttamente.
secure
Facoltativo. Qualsiasi gestore di URL può utilizzare l'impostazione secure, inclusi i gestori di file statici. L'elemento secure presenta i seguenti
valori possibili:
optional
Le richieste HTTP e HTTPS con URL corrispondenti al gestore hanno esito positivo senza reindirizzamenti. L'applicazione può esaminare la richiesta per determinare quale protocollo è stato utilizzato e rispondere di conseguenza. Questa è l'impostazione predefinita quando non viene fornito secure per un gestore.
never
Le richieste di un URL corrispondente a questo gestore che utilizzano HTTPS vengono reindirizzate automaticamente all'URL HTTP equivalente. Quando la richiesta HTTPS di un utente viene reindirizzata come richiesta HTTP, i parametri di ricerca vengono rimossi dalla richiesta. Questo impedisce a un utente di inviare accidentalmente dati di query su una connessione non sicura destinata a una connessione sicura.
always
Le richieste di un URL corrispondente a questo gestore che non utilizzano HTTPS vengono reindirizzate automaticamente all'URL HTTPS con lo stesso percorso. I parametri di query vengono conservati per il reindirizzamento.
Per
scegliere come target una versione specifica dell'app utilizzando il dominio REGION_ID.r.appspot.com, sostituisci i punti che in genere separano i componenti del sottodominio dell'URL con la stringa "-dot-", ad esempio: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
L'accesso e la disconnessione degli Account Google vengono sempre eseguiti utilizzando una connessione sicura, non correlata alla configurazione degli URL dell'applicazione.
static_dir
Facoltativo. Il percorso della directory contenente i file statici, dalla directory root dell'applicazione. Tutto ciò che dopo la fine del pattern url corrispondente viene aggiunto a static_dir per formare il percorso completo del file richiesto.
Ogni file nella directory statica viene gestito utilizzando il tipo MIME corrispondente all'estensione del nome file, a meno che non venga sostituito dall'impostazione mime_type della directory. Tutti i file nella directory specificata vengono caricati come file statici e nessuno può essere eseguito come script.
Esempio:
handlers:
# All URLs beginning with /stylesheets are treated as paths to
# static files in the stylesheets/ directory.
- url: /stylesheets
static_dir: stylesheets
# ...
static_files
Facoltativo. Un gestore di pattern di file statici associa un pattern URL ai percorsi dei file statici caricati con l'applicazione. L'espressione regolare
del pattern URL può definire raggruppamenti di espressioni regolari da utilizzare
nella creazione del percorso del file. Puoi utilizzare questo valore invece di static_dir per mappare file specifici in una struttura di directory senza mappare l'intera directory.
Esempio:
handlers:
# All URLs ending in .gif .png or .jpg are treated as paths to
# static files in the static/ directory. The URL pattern is a
# regular expression, with a grouping that is inserted into the
# path to the file.
- url: /(.*\.(gif|png|jpg))$
static_files: static/\1
upload: static/.*\.(gif|png|jpg)$
# ...
I file statici non possono essere uguali ai file di codice dell'applicazione.
upload
Facoltativo. Un'espressione regolare che corrisponde ai percorsi dei file di tutti i file a cui questo gestore farà riferimento. Questa operazione è necessaria perché il gestore non è in grado di determinare quali file nella directory dell'applicazione corrispondono ai pattern url e static_files specificati. I file statici vengono caricati e gestiti separatamente dai file dell'applicazione. L'esempio
riportato sopra potrebbe utilizzare il seguente pattern upload:
archives/(.*)/items/(.*)
url
Elemento obbligatorio in handlers. Il pattern URL, come espressione regolare che può contenere raggruppamenti. Ad esempio, /profile/(.*)/(.*) corrisponde all'URL /profile/edit/manager e utilizza edit e manager come primo e secondo raggruppamento.
Il pattern URL presenta alcune differenze di comportamento se utilizzato con i seguenti elementi:
Utilizza un prefisso URL. Il pattern express regolare non deve contenere raggruppamenti se utilizzato con l'elemento static_dir. Tutti gli URL che iniziano con questo prefisso vengono gestiti da questo gestore, utilizzando la parte dell'URL dopo il prefisso come parte del percorso del file.
Un gestore di pattern di file statici associa un pattern URL ai percorsi dei file statici caricati con l'applicazione. L'espressione regolare del pattern URL può definire raggruppamenti di espressioni regolari da utilizzare nella creazione del percorso del file. Puoi utilizzare questo valore invece di static_dir per mappare file specifici in una struttura di directory senza mappare l'intera directory.
Elementi di scalabilità
Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. Se non viene specificato alcun tipo di scalabilità, per impostazione predefinita viene impostata la scalabilità automatica.
Per saperne di più sulla scalabilità delle app di App Engine, consulta Tipi di scalabilità.
Elemento
Descrizione
automatic_scaling
Facoltativo. Applicabile solo per le applicazioni che utilizzano una classe istanza di F1 o superiore.
Specifica questo elemento per modificare le impostazioni predefinite per la scalabilità automatica, ad esempio l'impostazione dei livelli minimo e massimo per il numero di istanze, la latenza e le connessioni simultanee per un servizio.
Questo elemento può contenere i seguenti elementi:
max_instances
Facoltativo. Specifica un valore compreso tra 0 e 2147483647, dove zero disabilita l'impostazione.
Questo parametro specifica il numero massimo di istanze che App Engine può creare per questa versione del modulo. Questo è utile per limitare i costi di un modulo.
min_instances
Facoltativa. Il numero minimo di istanze che App Engine deve creare per questa versione del modulo. Queste istanze gestiscono il traffico all'arrivo delle richieste e continuano a gestire il traffico anche quando vengono avviate altre istanze in base alle necessità per gestire il traffico.
Specifica un valore compreso tra 0 e 1000. Puoi impostare il parametro sul valore 0 per consentire la scalabilità a 0 istanze per ridurre i costi quando non vengono gestite richieste. Tieni presente che ti viene addebitato
il numero di istanze specificato indipendentemente dal fatto che
ricevano o meno il traffico.
max_idle_instances
Facoltativo. Il numero massimo di istanze inattive che App Engine deve mantenere per questa versione. Specifica un valore compreso tra 1 e 1000. Se non specificato, il valore predefinito è automatic,
il che significa che App Engine gestirà
il numero di istanze inattive.
Tieni presente che:
Un valore massimo elevato riduce il numero di istanze inattive in modo più graduale quando i livelli di carico tornano alla normalità dopo un picco. Ciò consente all'applicazione di mantenere prestazioni stabili attraverso le fluttuazioni del carico di richieste, ma aumenta anche il numero di istanze inattive (e i conseguenti costi di esecuzione) durante questi periodi di carico elevato.
Un valore massimo basso consente di ridurre i costi di esecuzione, ma può ridurre le prestazioni a fronte di livelli di carico volatili.
Nota: quando si torna a livelli normali dopo un picco di carico, il numero di istanze inattive può temporaneamente superare il limite massimo specificato. Tuttavia, non ti verrà addebitato alcun costo per più istanze rispetto al numero massimo specificato.
min_idle_instances
(Facoltativo) Il numero di istanze aggiuntive da mantenere in esecuzione
e pronte a gestire il traffico per questa versione.
App Engine calcola il numero di istanze necessarie per gestire il traffico attuale dell'applicazione in base a impostazioni di scalabilità come target_cpu_utilization e target_throughput_utilization. L'impostazione min_idle_instances specifica il numero di istanze da eseguire oltre a questo numero calcolato. Ad esempio,
se App Engine calcola che sono necessarie 5 istanze
per gestire il traffico e min_idle_instances
è impostato su 2, App Engine eseguirà 7 istanze (5, calcolate
in base al traffico, più 2 aggiuntive per min_idle_instances).
Tieni presente che ti viene addebitato
il numero di istanze specificato indipendentemente dal fatto che
ricevano o meno il traffico. Tieni presente che:
Un minimo basso aiuta a mantenere bassi i costi di esecuzione durante i periodi di inattività, ma significa che un numero inferiore di istanze potrebbe essere immediatamente disponibili per rispondere a un picco di carico improvviso.
Un minimo elevato consente di preparare l'applicazione per rapidi picchi nel carico delle richieste. App Engine mantiene il numero minimo di istanze in esecuzione per gestire le richieste in entrata. Ti viene addebitato il numero di istanze specificato, indipendentemente dal fatto che stiano gestendo le richieste.
Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno effetto sulle prestazioni della tua applicazione.
target_cpu_utilization
Facoltativo. Specifica un valore compreso tra 0,5 e 0,95. Il valore predefinito è 0.6.
Questo parametro specifica la soglia di utilizzo della CPU entro la quale le nuove istanze inizieranno a gestire il traffico, consentendoti di trovare un equilibrio tra prestazioni e costi con valori più bassi che aumentano le prestazioni e i costi e valori più elevati che diminuiscono le prestazioni, ma riducono anche i costi. Ad esempio, un valore di 0,7 significa che le nuove istanze verranno avviate dopo che l'utilizzo della CPU avrà raggiunto il 70%.
target_throughput_utilization
Facoltativo. Specifica un valore compreso tra 0,5 e 0,95. Il valore predefinito è 0.6.
Utilizzato con max_concurrent_requests per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo. Quando il
numero di richieste in parallelo raggiunge un valore uguale a
max_concurrent_requests volte
target_throughput_utilization, lo scheduler cerca
di avviare una nuova istanza.
max_concurrent_requests
Facoltativo. Il numero di richieste in parallelo che un'istanza di scalabilità automatica può accettare prima che lo scheduler generi una nuova istanza (valore predefinito: 10, massimo: 1000).
Utilizzato con target_throughput_utilization per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo.
Quando il numero di richieste in parallelo raggiunge un valore uguale a
max_concurrent_requests volte
target_throughput_utilization, lo scheduler cerca di
avviare una nuova istanza.
Ti consigliamo di non impostare max_concurrent_requests
su un valore inferiore a 10, a meno che tu non abbia bisogno di un thread singolo. È probabile che un valore inferiore a 10 porti a creare più istanze del necessario per un'app threadsafe, il che potrebbe comportare costi inutili.
Se questa impostazione è troppo alta, potresti riscontrare un aumento della latenza dell'API. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima che venga raggiunto il numero massimo effettivo di richieste.
max_pending_latency
Il periodo di tempo massimo entro il quale App Engine deve consentire a una richiesta
di attendere nella coda in attesa prima di avviare altre istanze
per gestire le richieste in modo da ridurre latenza in sospeso. Quando questa soglia viene raggiunta, è un indicatore di cui fare lo scale up, che determina un aumento del numero di istanze.
Se non specificato, il valore predefinito è automatic. Ciò significa che le richieste possono rimanere nella coda in attesa per un massimo di 10 secondi, il
limite di tempo massimo per le richieste in attesa, prima che venga attivata la nuova istanza.
Un massimo basso significa che App Engine avvierà nuove istanze prima per le richieste in attesa, migliorando le prestazioni ma aumentando i costi di esecuzione.
Un valore massimo elevato significa che gli utenti potrebbero attendere più a lungo la pubblicazione delle loro richieste (se ci sono richieste in attesa e nessuna istanza inattiva per gestirle), ma l'esecuzione dell'applicazione avrà un costo inferiore.
min_pending_latency
Un elemento facoltativo che puoi impostare per specificare il tempo minimo entro il quale App Engine deve consentire di attendere una richiesta nella coda in attesa prima di avviare una nuova istanza per gestirla.
La specifica di un valore può ridurre i costi di esecuzione, ma aumentare il tempo di attesa degli utenti per la pubblicazione delle richieste.
Per le app gratuite, il valore predefinito è 500ms. Per le app a pagamento, il valore predefinito è 0.
Questo elemento interagisce con l'elemento max_pending_latency per determinare quando App Engine crea nuove istanze.
Se ci sono richieste in attesa in coda:
Meno del valore min_pending_latency specificato,
App Engine non creerà nuove istanze.
Se superi max_pending_latency, App Engine proverà a creare una nuova istanza.
Tra il periodo di tempo specificato da min_pending_latency e max_pending_latency, App Engine proverà a riutilizzare un'istanza esistente. Se nessuna istanza è in grado di elaborare la richiesta prima del giorno max_pending_latency, App Engine creerà una nuova istanza.
Le applicazioni che utilizzano una classe istanza B1 o successiva devono specificare questo elemento o manual_scaling.
Questo elemento consente la scalabilità di base delle classi di istanza B1 e successive. Può contenere i seguenti elementi:
max_instances
Obbligatorio. Il numero massimo di istanze che App Engine può creare per questa versione del servizio. Questo è utile per limitare i costi di un servizio.
idle_timeout
Facoltativo. L'istanza verrà arrestata per questo periodo di tempo dopo aver ricevuto l'ultima richiesta. Il valore predefinito è 5 minuti
(5m).
