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
all'area geografica selezionata al momento della creazione dell'app. Il codice non
corrisponde a un paese o a una provincia, anche se alcuni ID di area geografica potrebbero essere
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 area geografica è facoltativo nell'URL.
Configura le impostazioni dell'app App Engine nel file app.yaml.
Il file app.yaml contiene anche informazioni sul codice dell'app, ad esempio il runtime e l'identificatore della versione più recente.
Ogni servizio nella tua app ha il proprio file app.yaml, che funge da descrittore per il 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 Python 3, app.yaml deve contenere almeno una voce
runtime. Per una breve panoramica, consulta la pagina relativa alla definizione delle impostazioni di runtime.
Il formato YAML supporta i commenti. Una riga che inizia con un carattere di cancelletto (#) viene ignorata:
# This is a comment.
Per i pattern di URL e percorsi dei file viene usata la sintassi estesa delle espressioni regolari, esclusi gli elementi di confronto e le classi di confronto. Sono supportati i riferimenti a corrispondenze raggruppate (ad es. \1), così come le seguenti estensioni Perl: \w \W \s \S \d \D.
(Facoltativo) Imposta un periodo di cache predefinito globale per tutti i gestori di file statici per un'applicazione. Puoi anche configurare una durata della cache per gestori di file statici specifici. Il valore è una stringa di numeri e unità, separati da spazi, in cui le unità possono essere utilizzate d per giorni, h per ore, m per minuti e
s per 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.
Esempio:
runtime: python39 # or another supported version
default_expiration: "4d 5h"
handlers:
# ...
(Facoltativo)
Esegue l'override del comportamento di avvio predefinito eseguendo il comando entrypoint all'avvio della tua app. Affinché la tua app possa ricevere richieste HTTP, l'elemento entrypoint deve contenere un comando che avvia un server web in ascolto sulla porta 8080.
Viene pubblicato se viene raggiunta una scadenza prima che si verifichi
una risposta dalla tua app.
Il campo error_code è facoltativo. Se non è specificato, il file fornito
è la risposta all'errore predefinita dell'app.
file
Ogni voce del file indica un file statico da pubblicare 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 della tua app.
I dati sugli errori personalizzati devono essere inferiori a 10 kilobyte.
(Facoltativo)
Un elenco di pattern URL e delle descrizioni di gestione.
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 attivare questi servizi prima di poter ricevere richieste in entrata. Puoi abilitare il servizio per un'app Python 3 includendo una sezione inbound_services nel file app.yaml.
I seguenti valori sono disponibili a seconda della scalabilità del servizio:
Scalabilità automatica
F1, F2, F4, F4_1G
Predefinito: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 instance_class
è impostato su F2 o superiore, puoi ottimizzare le istanze
impostando max_concurrent_requests su un valore superiore a
quello 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 manuali e di base richiedono di specificare
l'elemento basic_scaling o l'elemento manual_scaling.
runtime
Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua app. Per specificare Python 3.9, utilizza:
runtime: python39
service
Obbligatorio se si crea 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 del progetto. Non può superare i 63 caratteri e non può iniziare o terminare 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 consente di specificare un
account di servizio gestito dall'utente come identità per la versione. L'account di servizio specificato verrà utilizzato per accedere ad altri servizi di Google Cloud ed eseguire attività.
(Facoltativo)
Configura la tua applicazione in modo che utilizzi un connettore di accesso VPC serverless, consentendo all'applicazione di inviare richieste alle risorse interne nella tua rete VPC. Per ulteriori informazioni, vedi 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
Valore predefinito. Le richieste agli indirizzi IP interni vengono inviate tramite il connettore di accesso VPC serverless nella rete VPC connessa. Le richieste a indirizzi IP esterni vengono inviate a Internet pubblica.
all-traffic
Tutte le richieste vengono inviate tramite il connettore Serverless VPC Access alla rete VPC connessa.
L'elemento handlers fornisce un elenco di pattern URL e le 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, come immagini, CSS o JavaScript.
I pattern vengono valutati nell'ordine in cui appaiono nel file app.yaml, 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 script, file statici,
directory statiche e altre impostazioni.
Elemento
Descrizione
auth_fail_action
(Facoltativo)
Questo elemento è supportato se
app_engine_apis è true.
Descrive l'azione intrapresa quando l'elemento login viene
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
/_ah/login_required se viene utilizzata l'autenticazione OpenID.
L'utente viene reindirizzato all'URL dell'applicazione dopo aver eseguito l'accesso
o creato un account.
unauthorized
La richiesta viene rifiutata con un codice di stato HTTP 401
e un messaggio di errore.
Se un'applicazione necessita di un comportamento diverso, l'applicazione stessa può implementare la gestione degli accessi degli utenti. Per ulteriori informazioni, consulta l'API
Users.
L'esempio seguente richiede un accesso per la directory /profile/ e un accesso come amministratore per la directory /admin/:
Puoi configurare un gestore in modo da rifiutare 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
configurazione del gestore:
expiration
(Facoltativo)
La durata di un file statico pubblicato da questo gestore deve essere memorizzato nella cache da proxy e browser web. Il valore è una stringa di
numeri e unità separati da spazi, in cui le unità possono essere
d per giorni, h per ore, m per
minuti e s per secondi. Ad esempio,
"4d 5h" imposta la scadenza della cache su 4 giorni e 5 ore dopo
la richiesta iniziale del file. Se omesso, viene usato il
default_expiration dell'applicazione. Consulta Scadenza
della cache per ulteriori dettagli.
http_headers
(Facoltativo) Puoi impostare intestazioni HTTP per le risposte dei gestori dei file o delle directory statici. Se devi impostare intestazioni HTTP
nei gestori script, devi farlo nel codice
dell'app. Per informazioni su quali intestazioni di risposta influiscono sulla memorizzazione nella cache, consulta la memorizzazione nella cache dei contenuti statici.
Esempio
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à è quello di supportare la condivisione delle risorse tra origini (CORS), ad esempio l'accesso a file ospitati da un'altra app 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 cerca di creare un elemento JavaScript
XMLHttpRequest in myassets, non avrà
esito positivo a meno che il gestore per myassets non restituisca
un'intestazione di risposta Access-Control-Allow-Origin: contenente
il valore http://mygame.uc.r.appspot.com.
Ecco come rendere il gestore del file statico restituire quel valore di intestazione della risposta richiesto:
Nota: se vuoi consentire a tutti di accedere alle tue risorse, puoi
utilizzare il carattere jolly '*' anziché
https://mygame.uc.r.appspot.com.
login
(Facoltativo)
Questo elemento è supportato se
app_engine_apis è true.
Determina se il gestore URL richiede che l'utente abbia eseguito l'accesso.
Questo elemento ha tre valori possibili:
optional
Valore predefinito. Non richiede l'accesso da parte dell'utente.
required
Se l'utente ha eseguito l'accesso, il gestore procede normalmente. In caso contrario,
viene intrapresa 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, riceverà 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 prima se l'utente ha eseguito l'accesso all'applicazione utilizzando la sua opzione di autenticazione. In caso contrario, l'utente viene reindirizzato per impostazione predefinita alla pagina di accesso. Puoi anche utilizzare auth_fail_action per
configurare l'app in modo da rifiutare semplicemente le richieste per un gestore da parte di utenti
non autenticati, anziché reindirizzare l'utente
alla pagina di accesso.
Nota: la limitazione di accesso admin è soddisfatta anche per le richieste interne per le quali App Engine imposta 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
required, perché le attività cron pianificate
non vengono eseguite come 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à estratto dall'estensione del nome file.
Se lo stesso file viene caricato con più estensioni, l'estensione risultante può dipendere dall'ordine in cui si sono verificati.
Per ulteriori informazioni sui possibili tipi di contenuti multimediali MIME, consulta il sito web IANA MIME Media Types
redirect_http_response_code
(Facoltativo) redirect_http_response_code viene utilizzato con l'impostazione
secure per configurare il codice di risposta HTTP restituito
quando si esegue un reindirizzamento richiesto dalla 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 reindirizzamento temporaneo.
Quando viene reindirizzata una richiesta di un utente, il codice di stato HTTP verrà impostato sul valore del parametro redirect_http_response_code. Se il parametro non è presente, verrà restituito 302.
script
(Facoltativo)
Specifica che le richieste al gestore specifico devono scegliere come target la tua app. L'unico valore accettato per l'elemento script è auto perché tutto il traffico viene pubblicato tramite il comando entrypoint. Per utilizzare i gestori statici, almeno uno dei
gestori deve contenere la riga script: auto
o definire un elemento entrypoint per eseguire correttamente il deployment.
secure
(Facoltativo) Qualsiasi gestore di URL può utilizzare l'impostazione secure, inclusi i gestori degli script e i gestori di file statici. L'elemento secure ha i seguenti
valori possibili:
optional
Sia le richieste HTTP che 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 secure non è fornito per un
gestore.
never
Le richieste di un URL che corrisponde a questo gestore che utilizzano HTTPS vengono
reindirizzate automaticamente all'URL HTTP equivalente. Quando una richiesta HTTPS di un utente viene reindirizzata a una richiesta HTTP, i parametri di ricerca vengono rimossi dalla richiesta. Ciò impedisce
a un utente di inviare accidentalmente dati delle query su una connessione
non sicura che era prevista per una connessione sicura.
always
Le richieste di un URL che corrisponde 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.
Esempio
handlers:
- url: /youraccount/.*
secure: always
script: auto
L'accesso e la disconnessione di Google Account 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 radice dell'applicazione. Tutto ciò che si trova 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 pubblicato utilizzando il tipo MIME corrispondente alla relativa 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 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 percorsi ai 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 utilizzarlo al posto 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 gli stessi dei file di codice dell'applicazione.
upload
(Facoltativo) Un'espressione regolare che corrisponde ai percorsi di tutti i file a cui verrà fatto riferimento da questo gestore. Ciò è necessario 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 precedente potrebbe utilizzare il seguente pattern upload: archives/(.*)/items/(.*)
url
Elemento obbligatorio in handlers. Il pattern URL, come espressione regolare. L'espressione può contenere raggruppamenti a cui è possibile fare riferimento nel percorso del file con lo script mediante riferimenti regolari alle espressioni. 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 quando 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 a percorsi di 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 utilizzarlo al posto di
static_dir per mappare file specifici in una struttura di
directory senza mappare l'intera directory.
Ridimensionare gli elementi
Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. Per ulteriori informazioni sulla scalabilità delle app di App Engine, consulta la pagina relativa ai tipi di scalabilità.
Elemento
Descrizione
automatic_scaling
(Facoltativo) Applicabile solo per applicazioni che utilizzano una classe di istanza di livello F1 o superiore.
Specifica questo elemento per modificare le impostazioni predefinite per la scalabilità automatica,
come 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
disattiva 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
(Facoltativo) Il numero minimo di istanze che App Engine deve creare per questa versione del modulo. Queste istanze forniscono traffico all'arrivo delle richieste e continuano a gestire il traffico anche quando vengono avviate altre istanze come richiesto 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 fornite richieste. Tieni presente che ti vengono addebitati i costi relativi al numero di istanze specificate, indipendentemente dal fatto che ricevano o meno 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 alla tua applicazione di mantenere prestazioni costanti tramite fluttuazioni nel carico delle richieste, ma anche di aumentare il numero di istanze inattive (e conseguenti costi di esecuzione) durante tali periodi di carico elevato.
Un limite massimo basso comporta costi inferiori, ma può peggiorare le prestazioni di parità a livelli di carico volatili.
Nota: quando si torna a livelli normali dopo un picco del carico, il numero di istanze inattive può superare temporaneamente il massimo specificato. Tuttavia, non ti verranno addebitate più istanze del numero massimo specificato.
min_idle_instances
Facoltativo: il numero di istanze aggiuntive da mantenere in esecuzione e pronta per gestire il traffico per questa versione.
App Engine calcola il numero di istanze necessarie per gestire il traffico attuale delle applicazioni in base a impostazioni di scalabilità come target_cpu_utilization e target_throughput_utilization. L'impostazione min_idle_instances
specifica il numero di istanze per
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ù altre 2 per min_idle_instances).
Tieni presente che ti vengono addebitati i costi relativi al numero di istanze specificate, indipendentemente dal fatto che ricevano o meno traffico. Tieni presente che:
Un minimo minimo aiuta a mantenere bassi i costi di esecuzione durante i periodi di inattività, ma significa che potrebbero essere immediatamente disponibili meno istanze per rispondere a un picco di carico improvviso.
Un minimo elevato consente di invocare l'applicazione per picchi
rapidi del 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 specificate, indipendentemente dal fatto che
gestiscano o meno le richieste.
Se imposti un numero minimo di istanze inattive, la latenza in sospeso avrà un effetto inferiore 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 in base alla quale le nuove istanze inizieranno
a gestire il traffico, consentendoti di bilanciare
prestazioni e costi con valori inferiori in grado di aumentare le prestazioni e
aumentare i costi, mentre i valori più alti diminuiscono le prestazioni, ma riducono anche i costi. Ad esempio, un valore pari a 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 pari a max_concurrent_requests volte target_throughput_utilization, il programma di pianificazione tenta 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 80).
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 pari a max_concurrent_requests volte target_throughput_utilization, il programma di pianificazione tenta 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 singolo thread. Un valore
inferiore a 10 può comportare la creazione di un numero di istanze maggiore di quello necessario per un'app threadsafe, il che potrebbe
comportare costi inutili.
Se questa impostazione è troppo alta, potresti riscontrare una maggiore
latenza API. Tieni presente che il programma di pianificazione potrebbe generare una nuova istanza prima
di raggiungere il numero massimo effettivo di richieste.
max_pending_latency
Periodo di tempo massimo in cui App Engine dovrebbe consentire a una richiesta
di attendere in coda in attesa prima di avviare istanze aggiuntive
per gestire le richieste in modo da ridurre la latenza in attesa. Quando si raggiunge questa soglia, si tratta di un indicatore di scale up, che comporta un aumento del numero di istanze.
Se non viene specificato, il valore predefinito è automatic. Ciò significa che le richieste possono rimanere nella coda in attesa per un massimo di 10 secondi, ovvero il limite massimo di richieste in attesa prima che venga attivata la nuova istanza.
Un limite basso indica che App Engine avvia nuove istanze
in anticipo per le richieste in attesa, migliorando le prestazioni ma aumentando i
costi di esecuzione.
Un numero massimo elevato indica che gli utenti potrebbero attendere più a lungo per la pubblicazione delle loro richieste (se sono presenti richieste in attesa e nessuna istanza inattiva al servizio), ma l'applicazione avrà un costo inferiore.
min_pending_latency
Un elemento facoltativo che puoi impostare per specificare il tempo minimo
in cui App Engine deve consentire una richiesta di attesa nella
coda in attesa prima di avviare una nuova istanza per gestirla.
Se specifichi un valore, puoi ridurre i costi di esecuzione, ma aumentare il tempo di attesa degli utenti prima che le richieste vengano pubblicate.
Per le app gratuite, il valore predefinito è 500ms. Per le app a pagamento, il valore predefinito è 0.
Questo elemento funziona insieme all'elemento max_pending_latency
per determinare quando App Engine crea nuove istanze.
Se le richieste in attesa sono in coda:
Inferiore al min_pending_latency specificato,
App Engine non creerà nuove istanze.
Più di max_pending_latency, App Engine tenterà di creare una nuova istanza.
Tra il periodo di tempo specificato da min_pending_latency
e max_pending_latency, App Engine tenterà
di 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.
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. Ciò è utile per limitare i costi di un servizio.
idle_timeout
(Facoltativo) L'istanza verrà arrestata questo periodo di tempo dopo
la ricezione dell'ultima richiesta. Il valore predefinito è 5 minuti
(5m).