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. 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.
Configura le impostazioni dell'app App Engine in app.yaml
di configurazione del deployment. 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
e deployment continuo. Devi prima creare il file app.yaml per il servizio default
prima di poter creare ed eseguire il deployment di file app.yaml per i servizi aggiuntivi all'interno di
la tua app. Per scoprire di più su come strutturare più servizi nella tua app, vedi
Strutturare i servizi web in App Engine.
Il formato YAML supporta i commenti. Una retta che inizia con il cancelletto (#)
viene ignorato:
# This is a comment.
I pattern per URL e percorsi file utilizzano l'espressione regolare estesa POSIX
, escludendo le regole di confronto
elementi e classi di confronto. Riferimenti precedenti a corrispondenze raggruppate (ad es. \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
app.yaml file.
Facoltativo. Imposta un periodo di cache predefinito globale per tutti i tipi di dati statici
gestori di file per un'applicazione. Puoi anche configurare una durata della cache per file statici specifici
e i gestori di rete. Il valore è una stringa di numeri e unità, separati da
spazi, dove le unità possono essere d per giorni, h per ore, m per minuti e
s per i secondi. Ad esempio, "4d 5h" imposta la scadenza della cache
a 4 giorni e 5 ore dalla prima richiesta del file. Se omesso,
il server di produzione imposta la scadenza a 10 minuti.
Facoltativo.
Puoi definire le variabili di ambiente in app.yaml
per renderle disponibili per la 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 qualsiasi carattere alfanumerico o "_").
Variabili di ambiente precedute dal prefisso
GAE sono riservate all'uso del sistema e non sono consentite in
app.yaml file.
error_handlers
Facoltativo.
Utilizzato per configurare pagine di errore personalizzate che vengono restituite per diverse
tipi di errori.
Questo elemento può contenere i seguenti elementi:
error_code
Facoltativa. error_code può essere uno dei seguenti:
Viene pubblicato se viene raggiunta una scadenza prima di ricevere una risposta da
la tua app.
.
error_code è facoltativo; se non è specificato, il file specificato
è la risposta di errore predefinita per la tua app.
file
Ogni voce di file indica un file statico che deve essere pubblicato in
della risposta di errore generico. Se specifichi
Elemento file senza un corrispondente
Elemento error_code, il file statico sarà il valore predefinito
pagina di errore relativa alla tua app.
I dati di errore personalizzati devono essere inferiori a 10 kilobyte.
Facoltativo.
Un elenco di pattern URL e descrizioni di come dovrebbero essere gestiti.
App Engine può gestire gli URL eseguendo il codice dell'applicazione oppure
tramite la pubblicazione di file statici caricati con il codice, ad esempio immagini, CSS
o JavaScript.
Facoltativo.
Le applicazioni devono attivare questi servizi prima di poter ricevere messaggi in entrata
richieste. Puoi abilitare il servizio per un'app
includendo una sezione inbound_services nella
app.yaml file.
I seguenti valori sono disponibili a seconda
del servizio
scalabilità:
Scalabilità automatica
F1, F2, F4 e F4_1G
Predefinito:F1
Facoltativamente, utilizza la
Elemento automatic_scaling per modificare il valore predefinito
impostazioni per la scalabilità automatica, come il valore minimo e massimo
numero di istanze, latenza e connessioni simultanee.
Nota: se instance_class
è impostato su F2 o su un valore superiore, puoi ottimizzare le tue istanze
impostando max_concurrent_requests a un valore superiore a
il valore predefinito è 10. Per determinare il valore ottimale,
aumentarlo gradualmente e monitorare il rendimento
un'applicazione.
Scalabilità di base e manuale
B1, B2, B4, B4_1G e B8
Predefinita:B2
Le classi di istanza di base e manuali richiedono di specificare
o basic_scaling o l'elemento manual_scaling.
main
Facoltativo.
Per Go, il percorso o il nome del pacchetto completo
pacchetto principale. Questa impostazione si applica solo se la tua app utilizza la modalità Modulo Go.
Devi dichiarare il percorso del pacchetto principale se
package main non si trova nella stessa directory del tuo
app.yaml. L'elemento main supporta file
percorsi relativi a app.yaml o nomi di pacchetti completi. Per
Ad esempio, se l'app ha questa struttura di directory:
Obbligatorio. Il nome dell'ambiente di runtime utilizzato dal tuo
dell'app. Ad esempio, per specificare l'ambiente di runtime, usa:
service
Obbligatorio se crei un
Google Cloud.
Facoltativo per default
completamente gestito di Google Cloud. Ogni servizio e ogni versione deve avere un nome. Un nome può
contenere numeri, lettere e trattini. La durata combinata
VERSION-dot-SERVICE-dot-PROJECT_ID, dove VERSION è il nome di
la tua versione, SERVICE è il nome del tuo servizio, e PROJECT_ID
è l'ID progetto, non può contenere più di 63 caratteri e non può
iniziano o terminano con un trattino. Scegli un nome univoco per ogni servizio
e ogni versione. Non riutilizzare i nomi tra servizi e versioni.
Esempio:
service: service-name
service_account
Facoltativo. L'elemento service_account ti consente di specificare
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 l'uso di un accesso VPC serverless
consentendo all'applicazione di inviare richieste ai server
delle tue risorse nella tua rete VPC. Per ulteriori informazioni, vedi
Connessione a una rete VPC.
name
Valore letterale stringa. Specifica il nome completo del tuo
Connettore di accesso VPC serverless tra virgolette:
Facoltativo. Il valore predefinito è private-ranges-only. La
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. Richieste a IP esterno
indirizzi IP vengono inviati alla rete internet pubblica.
all-traffic
Tutte le richieste vengono inviate tramite
Connettore di accesso VPC serverless
alla rete VPC connessa.
L'elemento handlers fornisce un elenco di URL
e descrizioni di come dovrebbero essere gestiti. App Engine può
gestire gli URL eseguendo il codice dell'applicazione o pubblicando file statici caricati
con il codice, ad esempio immagini, CSS o JavaScript.
I pattern vengono valutati nell'ordine in cui appaiono nel file app.yaml, a partire da
dall'alto verso il basso. Il primo mapping il cui pattern corrisponde all'URL è quello utilizzato
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
rispetto a Node.js e ad altre impostazioni.
Elemento
Descrizione
auth_fail_action
Per usare 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
Predefinita. L'utente viene reindirizzato alla pagina di accesso di Google oppure
/_ah/login_required se viene utilizzata l'autenticazione OpenID.
Una volta effettuato l'accesso, l'utente verrà reindirizzato all'URL dell'applicazione.
o la creazione di un account.
unauthorized
La richiesta è stata rifiutata con un codice di stato HTTP 401
e un messaggio di errore.
Se un'applicazione richiede un comportamento diverso, l'applicazione stessa può
implementare la gestione degli accessi utente. Ad esempio, richiedere l'accesso
per la directory /profile/ o per accedere come amministratore
nella directory /admin/. Vedi Utenti
API per saperne di più.
Puoi configurare un gestore per negare l'accesso agli URL protetti quando
l'utente non ha eseguito l'accesso, invece di reindirizzarlo alla
pagina di accesso, aggiungendo auth_fail_action: unauthorized alla
la configurazione del gestore.
expiration
Facoltativo.
Il periodo di tempo in cui un file statico pubblicato da questo gestore dovrebbe essere
memorizzati nella cache da proxy web e browser. 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
minuti e s per i secondi. Ad esempio:
"4d 5h" imposta la scadenza della cache su 4 giorni e 5 ore dopo
se viene richiesto per la prima volta. Se omesso, il valore
È in uso default_expiration. Vedi Cache
data di scadenza per ulteriori dettagli.
http_headers
Facoltativo. Puoi impostare HTTP
intestazioni per le risposte del file statico o della directory
e i gestori di rete.
Se devi impostare intestazioni HTTP
nei tuoi gestori script, devi invece farlo in
il codice della tua app. Per informazioni su quali intestazioni delle risposte
influenzare la memorizzazione nella cache,
consulta la sezione Memorizzazione nella cache
contenuti statici.
handlers:
- url: /images
static_dir: static/images
http_headers:
X-Foo-Header: foo
X-Bar-Header: bar value
vary: Accept-Encoding
# ...
Assistenza CORS
Un uso importante di questa funzionalità è supportare le risorse multiorigine
condivisione (CORS), ad esempio l'accesso a file ospitati da un altro
dell'app App Engine.
Ad esempio, potresti avere l'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 a myassets, non
riuscito a meno che il gestore di myassets non restituisca un
L'intestazione della risposta Access-Control-Allow-Origin: contiene
il valore http://mygame.uc.r.appspot.com.
Ecco come restituire il gestore di file statico
valore di intestazione risposta richiesto:
Suggerimento: per consentire a tutti di accedere ai tuoi asset, puoi:
utilizza il carattere jolly '*', anziché
https://mygame.uc.r.appspot.com.
login
Per usare questo elemento,
app_engine_apis deve essere impostato su true.
Facoltativo.
Determina se il gestore URL richiede che l'utente abbia firmato
in.
Questo elemento ha tre possibili valori:
optional
Predefinita. Non è necessario che l'utente abbia eseguito l'accesso.
required
Se l'utente ha eseguito l'accesso, il gestore procede normalmente. Altrimenti,
l'azione specificata in auth_fail_action
è già in uso.
admin
Come per required, esegue auth_fail_action
se l'utente non ha eseguito l'accesso. Inoltre, se l'utente non è un
amministratore dell'applicazione, verrà visualizzato un messaggio di errore
indipendentemente da auth_fail_action
dell'ambientazione. 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 controlla innanzitutto se
l'utente ha eseguito l'accesso all'applicazione utilizzando il suo
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 degli utenti
che non sono adeguatamente autenticati, anziché reindirizzare l'utente a
la pagina di accesso.
Nota: la limitazione dell'accesso di admin è soddisfatta anche per
per le quali App Engine imposta le richieste
X-Appengine intestazioni speciali. Ad esempio:
cron attività pianificate soddisfano le admin
perché App Engine imposta un'intestazione HTTP
X-Appengine-Cron: true sulle rispettive richieste.
Tuttavia, le richieste non soddisferanno i
required limitazione di accesso, perché le attività pianificate dalla cron
non vengono eseguiti come nessun utente.
mime_type
Facoltativo. Se specificato, tutti i file pubblicati da questo gestore saranno
pubblicati utilizzando il tipo MIME specificato. Se non specificato, il tipo MIME
per un file, verrà ricavata dall'estensione del nome file del file.
Se lo stesso file viene caricato con più estensioni,
può dipendere dall'ordine in cui sono stati eseguiti i caricamenti.
Facoltativo. redirect_http_response_code viene utilizzato con
Impostazione secure per configurare il codice di risposta HTTP restituito
quando si esegue un reindirizzamento richiesto da secure
l'impostazione è stata configurata.
L'elemento redirect_http_response_code ha quanto segue
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, viene impostato il codice di stato HTTP
al valore dell'attributo redirect_http_response_code
. Se il parametro non è presente, verrà restituito 302.
script
Facoltativo.
Specifica che le richieste al gestore specifico devono avere come target
dell'app. L'unico valore accettato per l'elemento script
è auto perché tutto il traffico viene gestito utilizzando la proprietà
il comando del punto di ingresso. Per poter utilizzare i gestori statici, devi avere almeno uno dei seguenti
i tuoi gestori devono contenere la riga script: auto
oppure definisci un elemento entrypoint di cui eseguire correttamente il deployment.
secure
Facoltativo. Qualsiasi gestore di URL può usare l'impostazione secure,
inclusi gestori di file statici. L'elemento secure ha quanto segue
valori possibili:
optional
Richieste sia HTTP che HTTPS con URL che corrispondono al gestore
hanno esito positivo senza reindirizzamenti. L'applicazione può esaminare la richiesta
per determinare quale protocollo è stato utilizzato e rispondere di conseguenza. Questo
è l'impostazione predefinita quando secure non viene fornito per un
.
never
Le richieste per un URL corrispondente a questo gestore che utilizzano HTTPS vengono
vengono reindirizzati automaticamente all'URL equivalente HTTP. Quando un utente
La richiesta HTTPS viene reindirizzata a una richiesta HTTP
vengono rimossi dalla richiesta. In questo modo
all'utente di inviare accidentalmente dati di query su una piattaforma
per una connessione sicura.
always
Le richieste per un URL corrispondente a questo gestore che non utilizzano HTTPS vengono
vengono reindirizzati automaticamente all'URL HTTPS con lo stesso percorso. Termine di ricerca
vengono conservati per il reindirizzamento.
.
A
scegliere come target una specifica versione dell'app utilizzando
REGION_ID.r.appspot.com
dominio, sostituisci i punti che generalmente separano
i componenti di 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 dall'Account Google vengono sempre eseguiti utilizzando un
connessione sicura, non correlata al modo in cui gli URL dell'applicazione
configurato.
static_dir
Facoltativo. Il percorso della directory contenente i file statici, da
nella directory radice dell'applicazione. Tutto ciò che dopo la fine
il pattern url corrispondente viene aggiunto a
static_dir per formare il percorso completo del file richiesto.
Ogni file nella directory statica viene pubblicato utilizzando il tipo MIME che
corrisponde alla relativa estensione del nome file a meno che non venga sostituito dal
dell'impostazione mime_type della directory. Tutti i file nel
una determinata directory vengono caricati come file statici
nessuno di questi 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 a
i percorsi dei file statici caricati con l'applicazione. Pattern URL
l'espressione regolare può definire i raggruppamenti di espressioni regolari da utilizzare
nella costruzione del percorso del file. Puoi utilizzarlo al posto di
static_dir per mappare file specifici in una directory
senza dover 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 per tutti
file a cui fa riferimento questo gestore. Questa operazione è necessaria
perché il gestore non è in grado di determinare quali file nella tua applicazione
della directory corrispondano agli attributi urlstatic_files pattern. I file statici vengono caricati
e vengono gestiti separatamente dai file dell'applicazione. L'esempio
in alto potrebbe utilizzare il seguente pattern upload:
archives/(.*)/items/(.*)
url
Elemento obbligatorio in handlers. Il pattern URL, come
un'espressione regolare che può contenere raggruppamenti. Ad esempio:
/profile/(.*)/(.*) corrisponde all'URL
/profile/edit/manager e utilizza
edit e manager come primo e secondo
e i raggruppamenti.
Il pattern URL presenta alcune differenze di comportamento se utilizzato con
i seguenti elementi:
Utilizza un prefisso URL. Il pattern espresso normale non deve contenere
raggruppamenti quando utilizzato con l'elemento static_dir. Tutti
Gli URL che iniziano con questo prefisso vengono gestiti da questo gestore, utilizzando
la porzione dell'URL che segue il prefisso come parte del percorso del file.
Un gestore di pattern di file statici associa un pattern URL ai percorsi da
i file statici caricati con l'applicazione. Il pattern URL è regolare
può definire raggruppamenti di espressioni regolari da utilizzare nel
del percorso del file. Puoi utilizzarlo al posto di
static_dir per mappare file specifici in una directory
senza dover mappare l'intera directory.
Elementi di scalabilità
Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. In caso contrario
del tipo specificato, la scalabilità automatica è impostata per impostazione predefinita.
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 un'etichetta
istanza
F1 o superiore.
Specifica questo elemento per modificare le impostazioni predefinite della scalabilità automatica.
come l'impostazione dei livelli minimo e massimo per il numero di istanze,
latenza e connessioni simultanee per un servizio.
Questo elemento può contenere i seguenti elementi:
max_instances
Facoltativa. Specifica un valore compreso tra 0 e 2147483647, dove zero
disattiva l'impostazione.
Questo parametro specifica il numero massimo di istanze per l'applicazione
Motore da creare per questa versione del modulo. È utile per limitare
solo i costi di un modulo.
min_instances
Facoltativa. Il numero minimo di istanze che App Engine deve
per questa versione del modulo. Queste istanze gestiscono il traffico quando
e continuano a gestire il traffico anche
e 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 delle istanze
Ridurre i costi se non vengono gestite richieste. Tieni presente che stai
addebitato per il numero di istanze specificato
che ricevono traffico o meno.
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 ulteriormente il numero di istanze inattive
gradualmente quando i livelli di carico tornano alla normalità dopo un picco. Questo
consente alla tua applicazione di mantenere un rendimento costante
delle fluttuazioni nel carico delle richieste, ma aumenta anche il numero di
di Compute Engine (e conseguenti costi di esecuzione) durante questi periodi
carico di lavoro.
Un valore massimo basso riduce i costi di gestione, ma può ridurne la qualità
le prestazioni a fronte di livelli di carico volatile.
Nota:per tornare ai livelli normali dopo un
un picco di carico, il numero di istanze inattive può superare temporaneamente
il valore massimo specificato. Tuttavia, non ti verrà addebitato alcun costo
più istanze rispetto al numero massimo specificato.
min_idle_instances
(Facoltativo) Il numero di istanze aggiuntive da mantenere in esecuzione
e pronto a gestire il traffico
per questa versione.
App Engine calcola il numero di istanze necessarie
gestire il traffico attuale delle applicazioni in base alla scalabilità
impostazioni come target_cpu_utilization e
target_throughput_utilization. Impostazione di min_idle_instances
specifica il numero di istanze a cui
eseguire in aggiunta a questo numero calcolato. Ad esempio:
se App Engine calcola 5 istanze
sono necessarie per gestire il traffico e min_idle_instances
è impostato su 2, App Engine eseguirà 7 istanze (5, calcolate
in base al traffico, più altri 2 per min_idle_instances).
Tieni presente che stai
addebitato per il numero di istanze specificato
che ricevono traffico o meno. Tieni presente che:
Un minimo basso aiuta a mantenere bassi i costi di esercizio in caso di inattività
ma significa che un numero minore di istanze potrebbe
disponibili per rispondere a un improvviso picco di carico.
Un minimo elevato ti consente di preparare l'applicazione
dei picchi nel carico delle richieste. App Engine mantiene il minimo
di istanze in esecuzione per gestire le richieste in entrata. Tu
il costo viene addebitato per il numero di istanze specificato,
non stanno gestendo le richieste.
Se imposti un numero minimo di istanze inattive, latenza in sospeso
avrà meno impatto sulle prestazioni della tua applicazione.
target_cpu_utilization
Facoltativa. Specifica un valore compreso tra 0,5 e 0,95. L'impostazione predefinita è
0.6.
Questo parametro specifica
la soglia di utilizzo della CPU alla quale le nuove istanze
iniziato a gestire il traffico, consentendoti di bilanciare
le prestazioni e i costi, con valori più bassi che aumentano le prestazioni e
un aumento dei costi e valori più alti che riducono il rendimento,
e la riduzione dei costi. Ad esempio, il valore 0,7 significa che
vengono avviate quando l'utilizzo della CPU raggiunge il 70%.
target_throughput_utilization
Facoltativa. Specifica un valore compreso tra 0,5 e 0,95. L'impostazione predefinita è
0.6.
Utilizzato con max_concurrent_requests per specificare quando
viene avviata una nuova istanza a causa di richieste in parallelo. Quando
di richieste in parallelo raggiunge un valore uguale a
max_concurrent_requests volte
target_throughput_utilization, lo scheduler prova
per avviare una nuova istanza.
max_concurrent_requests
Facoltativo. Il numero di richieste in parallelo e una scalabilità automatica
l'istanza può accettare prima che lo scheduler crei 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 prova a
avviare una nuova istanza.
Ti consigliamo di non impostare max_concurrent_requests
a meno di 10, a meno che tu non abbia bisogno di un singolo thread. Un valore
meno di 10, è probabile che un numero maggiore di istanze
del necessario per un'app threadsafe, con possibili conseguenze
costi inutili.
Se questa impostazione è troppo alta, l'API potrebbe essere aumentata
una latenza di pochi millisecondi. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima
viene raggiunto il numero massimo effettivo di richieste.
max_pending_latency
Il periodo di tempo massimo che App Engine deve consentire di inviare una richiesta
di attendere in coda prima di avviare istanze aggiuntive
per gestire le richieste in modo da ridurre
latenza in sospeso. Quando questo
soglia è stata raggiunta, è un segnale di fare lo scale up e
un aumento del numero di istanze.
Se non specificato, il valore predefinito è automatic. Ciò significa
possono rimanere nella coda di attesa per un massimo di 10 secondi, il limite massimo
in attesa del limite di tempo per le richieste in attesa, prima dell'attivazione della nuova istanza.
Un valore massimo basso significa che App Engine avvierà nuove istanze
per le richieste in attesa, migliorando il rendimento e aumentando
i costi di gestione.
Un valore massimo elevato significa che gli utenti potrebbero attendere più a lungo per le loro richieste
la pubblicazione (se ci sono richieste in attesa e non
di Compute Engine, ma la tua applicazione costerà meno
vengono eseguiti tutti i test delle unità.
min_pending_latency
Un elemento facoltativo che puoi impostare per specificare la quantità minima
tempo in cui App Engine deve consentire l'attesa di una richiesta
in attesa prima di avviare una nuova istanza per gestirla.
Specificare un valore può ridurre i costi di gestione, ma aumentare il tempo
Gli utenti devono attendere
la risposta alle loro richieste.
Per le app gratuite, il valore predefinito è 500ms. A pagamento
app, il valore predefinito è 0.
Questo elemento funziona insieme a max_pending_latency
per determinare quando App Engine crea nuove istanze.
Se sono presenti richieste in attesa in coda:
Meno del valore di min_pending_latency specificato,
App Engine non creerà nuove istanze.
Più di max_pending_latency, App Engine
proverà a creare una nuova istanza.
Tra l'orario specificato da min_pending_latency
e max_pending_latency, App Engine eseguirà
e provare 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.
