Riferimento appengine-web.xml

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 regione possono sembrare simili 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.

Devi utilizzare il file appengine-web.xml per configurare l'app solo se stai eseguendo la migrazione di un'app esistente dal runtime di App Engine Java 8 alla versione Java più recente supportata e vuoi utilizzare i servizi in bundle legacy. Se utilizzi un appengine-web.xml nel progetto, app.yaml viene generato automaticamente al momento del deployment.

Le applicazioni Java di App Engine utilizzano un file di configurazione, denominato appengine-web.xml, per specificare informazioni sull'app e per identificare quali file all'interno del file WAR dell'app sono file statici (ad esempio, immagini) e quali file di risorse utilizzati dall'applicazione.

Sintassi

Un'app Java di App Engine deve avere un file denominato appengine-web.xml nella relativa WAR, nella directory WEB-INF/. Questo è un file XML il cui elemento principale è <appengine-web-app>.

Puoi trovare la definizione del tipo di documento e le specifiche dello schema per appengine-web.xml nella directory docs/ dell'SDK.

Elemento	Descrizione
`<application>`	Non richiesto se esegui il deployment della tua app utilizzando strumenti basati su Google Cloud SDK, come il comando `gcloud app deploy`, i plug-in IntelliJ o Eclipse e i plug-in Maven o Gradle. Gli strumenti basati su Google Cloud SDK ignorano questo elemento e recuperano l'ID progetto dalla proprietà del progetto gcloud config. Tieni presente che sebbene sia possibile eseguire l'override dell'ID progetto utilizzando lo strumento a riga di comando gcloud, viene impostato un ID progetto a livello di macchina, il che può causare confusione se stai sviluppando più progetti. L'elemento `<application>` contiene l'ID progetto dell'applicazione. Questo è l'ID progetto che registri quando crei il tuo progetto nella console Google Cloud.
`<app-engine-apis>`	Facoltativo. Se vuoi utilizzare i servizi in bundle legacy di App Engine per i runtime di seconda generazione, imposta questo campo su `true`.
`<entrypoint>`	Facoltativo e solo per i runtime di seconda generazione. Esegue l'override del punto di ingresso predefinito, ovvero la riga di comando del processo che avvia l'applicazione Java. Per impostazione predefinita, il punto di ingresso generato per una classe di istanza F4 (le impostazioni di memoria vengono calcolate dalla classe di istanza) equivale alla seguente configurazione: <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <entrypoint> java -showversion -Xms32M -Xmx819M -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:+PrintCommandLineFlags --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.logging/java.util.logging=ALL-UNNAMED --add-opens java.base/java.util.concurrent=ALL-UNNAMED -Dclasspath.runtimebase=/base/java_runtime -Djava.class.path=/base/java_runtime/runtime-main.jar -Djava.library.path=/base/java_runtime: com/google/apphosting/runtime/JavaRuntimeMainWithDefaults --fixed_application_path=/workspace /base/java_runtime </entrypoint> </appengine-web-app> Puoi modificare la configurazione per aggiungere ulteriori flag di processo JVM o definire un processo di avvio personalizzato. Il deployment dell'applicazione è stato eseguito nella directory `/workspace`, mentre i JAR di runtime si trovano nella directory `/base/java_runtime`. Scopri come personalizzare il punto di ingresso per il runtime Java utilizzando le variabili di ambiente..
`<async-session-persistence>`	Facoltativo. È possibile ridurre la latenza delle richieste configurando la tua applicazione per la scrittura asincrona dei dati delle sessioni HTTP nel datastore: <async-session-persistence enabled="true" /> Quando la persistenza della sessione asincrona è attivata, App Engine invia un'attività della coda di attività per scrivere i dati della sessione nel datastore prima di scriverli in memcache. Per impostazione predefinita, l'attività verrà inviata alla coda "predefinita". Se vuoi utilizzare una coda diversa, aggiungi l'attributo "queue-name": <async-session-persistence enabled="true" queue-name="myqueue"/> I dati della sessione sono sempre scritti in modo sincrono in memcache. Se una richiesta tenta di leggere i dati della sessione quando memcache non è disponibile (o i dati della sessione sono stati svuotati), verrà eseguito il failover su Datastore, che potrebbe non disporre ancora dei dati della sessione più recenti. Ciò significa che la persistenza della sessione asincrona può causare la visualizzazione da parte dell'applicazione dei dati di sessione inattivi. Tuttavia, per la maggior parte delle applicazioni, il vantaggio della latenza supera di gran lunga il rischio.
`<auto-id-policy>`	Facoltativo. Se imposti automaticamente gli identificatori di entità, puoi modificare il metodo utilizzato impostando il criterio ID automatico. Di seguito sono riportate le opzioni valide: `default` Predefinita. Utilizza ID automatici sparsi, ovvero numeri interi ben distribuiti, grandi e sufficientemente piccoli da essere rappresentati da valori in virgola mobile a 64 bit. `legacy` L'opzione precedente verrà ritirata in una release futura e verrà rimossa. Per ulteriori informazioni, consulta il post del blog che annuncia questa modifica.
`<automatic-scaling>`	Facoltativo. Per una spiegazione completa, consulta la sezione relativa alla scalabilità automatica.
`<basic-scaling>`	Facoltativo. Per una spiegazione completa, consulta la sezione relativa alla scalabilità di base.
`<env-variables>`	Facoltativo. Il file `appengine-web.xml` può definire le variabili di ambiente che vengono impostate quando l'applicazione è in esecuzione. <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> Per evitare conflitti con l'ambiente locale, il server di sviluppo non imposta le variabili di ambiente basate su questo file e richiede che queste variabili siano già impostate nell'ambiente locale sui valori corrispondenti. export DEFAULT_ENCODING="UTF-8" dev_appserver war Al momento del deployment in App Engine, l'ambiente viene creato con queste variabili già impostate.
`<inbound-services>`	Facoltativo. Prima che un'applicazione possa ricevere email, è necessario che sia configurata per abilitare il servizio. Puoi abilitare il servizio per un'app Java includendo una sezione `<inbound-services>` nel file `appengine-web.xml`. È disponibile il seguente servizio in entrata: `mail` Consente all'applicazione di ricevere posta.
`<instance-class>`	Facoltativo. La dimensione della classe di istanza per questo modulo. Quando specifichi diverse opzioni di scalabilità, sono disponibili le seguenti classi di istanza: `automatic_scaling` Quando si utilizza la scalabilità automatica, sono disponibili le classi di istanza F1, F2, F4 e F4_1G. Predefinito:F1 viene assegnato se non specifichi una classe di istanza insieme all'elemento `automatic_scaling`. `basic_scaling` Quando si utilizza la scalabilità di base, sono disponibili le classi di istanza B1, B2, B4, B4_1G e B8. Predefinito:viene assegnato B2 se non specifichi una classe di istanza insieme all'elemento `basic_scaling`. `manual_scaling` Quando utilizzi la scalabilità manuale, sono disponibili le classi di istanza B1, B2, B4, B4_1G e B8. Predefinito:viene assegnato B2 se non specifichi una classe di istanza insieme all'elemento `manual_scaling`. Nota: se `instance-class` è impostato su `F2` o su un valore superiore, puoi ottimizzare le istanze impostando `max-concurrent-requests` su un valore superiore a 10 (valore predefinito). Per trovare il valore ottimale, aumentalo gradualmente e monitora le prestazioni della tua applicazione.
`<manual-scaling>`	Facoltativo. Per una spiegazione completa, consulta la sezione relativa alla scalabilità manuale.
`<precompilation-enabled>`	Facoltativo. App Engine utilizza un processo di "precompilazione" con il bytecode Java di un'app per migliorare le prestazioni dell'app nell'ambiente di runtime Java. Il codice precompilato funziona in modo identico al bytecode originale. Se per qualche motivo preferisci che la tua app non utilizzi la precompilazione, puoi disattivarla aggiungendo quanto segue al file `appengine-web.xml`: <precompilation-enabled>false</precompilation-enabled>
`<module>`	Nota: i moduli sono ora denominati Servizi, mentre i servizi vengono ancora dichiarati nei file `appengine-web.xml` come moduli, ad esempio: `<module>service_name</module>`. Obbligatorio se stai creando un servizio. Facoltativo per il servizio predefinito. Ogni servizio e ogni versione devono avere un nome. Un nome può contenere numeri, lettere e trattini. Non può superare i 63 caratteri, iniziare o terminare con un trattino e contenere la stringa "-dot". Scegli un nome univoco per ogni servizio e ogni versione. Non riutilizzare i nomi tra servizi e versioni. Vedi anche service.
`<public-root>`	Facoltativo. `<public-root>` è una directory dell'applicazione che contiene i file statici per l'applicazione. Quando viene effettuata una richiesta per un file statico, il `<public-root>` per l'applicazione viene anteposto al percorso della richiesta. Fornisce il percorso di un file dell'applicazione contenente i contenuti richiesti. Il valore predefinito di `<public-root>` è `/`. Ad esempio, quanto segue mappa il percorso dell'URL `/index.html` al percorso del file dell'applicazione `/static/index.html`: <public-root>/static</public-root>
`<resource-files>`	Facoltativo. I file elencati nell'elemento `<resource-files>` sono accessibili dal codice dell'applicazione utilizzando il file system. Questi file vengono archiviati sui server delle applicazioni insieme all'app, anziché nel modo in cui i file statici vengono archiviati e pubblicati. L'elemento `<resource-files>` può contenere i seguenti elementi: `<include>` Un elemento `<include>` designa i file come file di risorse e disponibili per il codice dell'applicazione. Questi file sono disponibili solo per il tuo codice in sola lettura e non per la gestione del traffico. Inclusione ed esclusione di file. `<exclude>` I file e le directory che corrispondono ai pattern `<exclude>` non verranno caricati o disponibili per il codice dell'applicazione. Tuttavia, questi file e directory continueranno a essere accessibili all'applicazione durante l'esecuzione sul server di sviluppo locale. Per maggiori informazioni, consulta Inclusione ed esclusione di file. Esempio: <resource-files> <include path="/.xml" /> <exclude path="/feeds/.xml" /> </resource-files> Questo esempio mostra come designare tutti i file `.xml` come file di risorse, ad eccezione di quelli nella directory `feeds/` e in tutte le relative sottodirectory. I file di risorse App Engine vengono letti utilizzando `java.io.File` o `javax.servlet.ServletContext.getResource/getResourceAsStream`. Non sono accessibili tramite `Class.getResourceAsStream()`.
`<runtime>`	Per utilizzare l'ultima versione di Java supportata, devi specificare questa voce con il valore `java21`. Esempio: <runtime>java21</runtime>
`<service>`	I servizi in precedenza erano noti come moduli. Attualmente, la definizione di un servizio come `<service>service_name</service >` è supportata solo dai comandi gcloud app.
`<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 Google Cloud ed eseguire attività. Esempio: <service-account>[SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com</service-account>
`<sessions-enabled>`	Facoltativo. App Engine include un'implementazione di sessioni, utilizzando l'interfaccia di sessione Servit. L'implementazione archivia i dati di sessione in Datastore per la persistenza e utilizza memcache per la velocità. Come per la maggior parte degli altri container servlet, gli attributi di sessione impostati con "session.setAttribute()" durante la richiesta vengono mantenuti alla fine di quest'ultima. Questa funzionalità è disattivata per impostazione predefinita. Per attivarlo, aggiungi quanto segue a `appengine-web.xml`: Esempio: <sessions-enabled>true</sessions-enabled> L'implementazione crea entità Datastore del tipo `_ah_SESSION` e voci memcache utilizzando chiavi con un prefisso di `_ahs`. Puoi eliminare queste entità utilizzando il modello Dataflow. Nota: poiché App Engine archivia i dati di sessione in Datastore e memcache, tutti i valori archiviati nella sessione devono implementare l'interfaccia `java.io.Serializable`. Vedi l'elemento `async-session-persistence` per ridurre la latenza per l'archiviazione dei dati delle sessioni.
`<ssl-enabled>`	Facoltativo. Per impostazione predefinita, qualsiasi utente può accedere a qualsiasi URL tramite HTTP o HTTPS. Puoi configurare un'app in modo che richieda HTTPS per determinati URL nel descrittore di deployment. Consulta la pagina relativa al descrittore del deployment: URL protetti. Se vuoi impedire l'utilizzo di HTTPS per l'applicazione, inserisci quanto segue nel file `appengine-web.xml`: <ssl-enabled>false</ssl-enabled> Non esiste un modo per non consentire HTTPS per alcuni percorsi URL e non per altri nell'ambiente di runtime Java.
`<static-error-handlers>`	Facoltativo. Quando si verificano determinati errori, App Engine pubblica una pagina di errore generica. Puoi configurare la tua app in modo che pubblichi un file statico personalizzato al posto di queste pagine di errore generiche, a condizione che i dati di errore personalizzati siano inferiori a 10 kilobyte. Puoi configurare diversi file statici da pubblicare per ogni codice di errore supportato specificando i file nel file `appengine-web.xml` dell'app. Per pubblicare pagine di errore personalizzate, aggiungi una sezione `<static-error-handlers>` a `appengine-web.xml`, come in questo esempio: <static-error-handlers> <handler file="default_error.html" /> <handler file="over_quota.html" error-code="over_quota" /> </static-error-handlers> Avviso: assicurati che il percorso del file di risposta all'errore non si sovrapponga ai percorsi dei gestori di file statici. Ogni voce `file` indica un file statico da pubblicare al posto della risposta di errore generica. `error-code` indica quale codice di errore deve causare la pubblicazione del file associato. I codici di errore supportati sono i seguenti: `over_quota` Indica che l'app ha superato una quota di risorse. `timeout` Questa notifica viene inviata se viene raggiunta una scadenza prima che l'app riceva una risposta. `error-code` è facoltativo; se non è specificato, il file fornito è la risposta di errore predefinita per la tua app. Facoltativamente, puoi specificare un `mime-type` da utilizzare quando viene pubblicato l'errore personalizzato. Consulta un elenco completo dei tipi di MIME.
`<static-files>`	Facoltativo. L'elemento `<static-files>` specifica pattern corrispondenti ai percorsi dei file da includere ed escludere dall'elenco dei file statici, sostituendo o modificando il comportamento predefinito. I file statici vengono pubblicati da server e cache dedicati, separati dai server delle applicazioni, utili per la pubblicazione di contenuti statici come immagini, fogli di stile CSS o file JavaScript. L'elemento `<static-files>` può contenere i seguenti elementi: `<include>` Un elemento `<include>` sostituisce il comportamento predefinito di inclusione di tutti i file non JSP. L'elemento `<include>` può specificare le intestazioni HTTP da utilizzare quando si risponde alla richiesta per le risorse specificate. Per maggiori informazioni, consulta Inclusione ed esclusione dei file. Puoi eseguire l'override della scadenza predefinita della cache statica specificando l'attributo `expiration` nell'elemento include. 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. Per maggiori informazioni, consulta la sezione Scadenza della cache. `<exclude>` I file e le directory che corrispondono ai pattern `<exclude>` non verranno caricati quando esegui il deployment dell'app in App Engine. Tuttavia, questi file e directory saranno comunque accessibili all'applicazione quando viene eseguita sul server di sviluppo locale. Per maggiori informazioni, consulta Inclusione ed esclusione dei file. Esempio <static-files> <include path="/my_static-files" > <http-header name="Access-Control-Allow-Origin" value="http://example.org" /> </include> </static-files>
`<system-properties>`	Facoltativo. Il file `appengine-web.xml` può definire le proprietà di sistema e le variabili di ambiente impostate quando l'applicazione è in esecuzione. <system-properties> <property name="myapp.maximum-message-length" value="140" /> <property name="myapp.notify-every-n-signups" value="1000" /> <property name="myapp.notify-url" value="http://www.example.com/signupnotify" /> </system-properties> <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> A partire da Java 21, puoi configurare il server web Java per l'utilizzo di thread virtuali. Ad esempio: <system-properties> <property name="appengine.use.virtualthreads" value="true"/> </system-properties> Per saperne di più sul supporto dei thread, vedi Jetty 12 - Supporto di Thread virtuali.
`<url-stream-handler>`	Facoltativo. Valori possibili: `native` o `urlfetch`. Il valore predefinito è `native`, il che significa che le classi di rete Java standard utilizzano il trasporto HTTP(S) Java standard. Per utilizzare questa impostazione, devi abilitare la fatturazione per la tua app. In caso contrario, riceverai delle eccezioni, descritte nella sezione Richieste di problemi. Se imposti `url-stream-handler` su `urlfetch`, `URL.openConnection` e i metodi correlati utilizzeranno il recupero URL per il trasporto `http` e `https`. <url-stream-handler>urlfetch</url-stream-handler>
`<version>`	L'elemento `<version>` contiene l'identificatore della versione più recente del codice dell'app. L'identificatore di versione può contenere lettere minuscole, cifre e trattini. Non può iniziare con il prefisso "ah-" e i nomi "default" e "latest" sono riservati e non possono essere utilizzati. I nomi di versione devono iniziare con una lettera per distinguerli dalle istanze numeriche sempre specificate da un numero. Ciò consente di evitare l'ambiguità con URL come `123.my-module.uc.r.appspot.com`, che può essere interpretato in due modi: se esiste la versione "123", la destinazione sarà la versione "123" del modulo in questione. Se questa versione non esiste, la destinazione sarà il numero di istanza 123 della versione predefinita del modulo.
`<warmup-requests-enabled>`	Facoltativo. Valore predefinito: true. Le richieste di warmup sono abilitate per impostazione predefinita per le applicazioni Java. Con le richieste di warmup abilitate, l'infrastruttura di App Engine invia richieste "GET" a `/_ah/warmup`, inizializzando servlet `<load-on-startup>`, `ServletContextListeners` e servlet di warmup personalizzati, che ti consentono di inizializzare il codice della tua applicazione in base alle esigenze. Potresti dover implementare un tuo gestore per `/_ah/warmup`, a seconda di quale di questi metodi scegli. Per disabilitare le richieste di warmup, specifica `false` per questo elemento: <warmup-requests-enabled>false</warmup-requests-enabled>
`<vpc-access-connector>`	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. Specifica il nome completo di un connettore nell'elemento `<name>`: <vpc-access-connector> <name>projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]</name> </vpc-access-connector> Per maggiori informazioni, consulta Connessione alle risorse interne in una rete VPC.

Ridimensionare gli elementi

La tabella seguente elenca le opzioni per definire come specificare la scalabilità dell'applicazione.

Per un confronto delle funzionalità relative alle prestazioni dei tipi di scalabilità, consulta Scalabilità delle istanze dinamiche.

Elemento Descrizione

Elemento	Descrizione
`<automatic-scaling>`	Facoltativo. Se non diversamente specificato, la scalabilità automatica si presume per impostazione predefinita con una classe di istanza predefinita `F1`. L'elemento `automatic_scaling` imposta i livelli minimo e massimo di numero di istanze, latenza e connessioni simultanee per un modulo. Questo elemento può contenere i seguenti elementi: `<target-cpu-utilization>` Facoltativo. Specifica un valore compreso tra 0,5 e 0,95. Questo parametro specifica la soglia di utilizzo della CPU al quale le nuove istanze inizieranno a gestire il traffico. In questo modo potrai trovare un equilibrio tra prestazioni e costi, con valori più bassi che aumentano le prestazioni e i costi e i valori più alti diminuiscono le prestazioni, ma anche i costi. Ad esempio, un valore pari a 0,7 indica 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. 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 avvia una nuova istanza. `<max-instances>` Facoltativo. Il numero massimo di istanze che App Engine può creare per questa versione dell'applicazione. Questo è utile per limitare i costi di un modulo. Specifica un valore compreso tra 0 e 2147483647. `<min-instances>` Facoltativo. Il numero minimo di istanze da creare con App Engine 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 richieste 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-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). Se questa impostazione è troppo elevata, 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. Nota: se `instance-class` è impostato su `F2` o su un valore superiore, puoi ottimizzare le istanze impostando `max-concurrent-requests` su un valore superiore a 10, che è il valore predefinito. Per trovare il valore ottimale, aumentalo gradualmente e monitora le prestazioni della tua applicazione. `<max-idle-instances>` Il numero massimo di istanze inattive che App Engine deve mantenere per questa versione. Il valore predefinito è "automatico". 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 delle 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ò compromettere 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 un numero di istanze superiore a quello specificato. `<max-pending-latency>` Il tempo massimo che 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. Un valore massimo basso significa che App Engine avvia prima nuove istanze per le richieste in attesa, migliorando le prestazioni ma aumentando i costi di esecuzione. Un massimo elevato significa che gli utenti potrebbero attendere più a lungo per la gestione delle loro richieste, se sono presenti richieste in attesa e nessuna istanza inattiva per gestirle, ma l'esecuzione dell'applicazione avrà un costo inferiore. `<min-idle-instances>` Il numero di istanze da mantenere in esecuzione e pronte per gestire il traffico.Questa impostazione si applica solo alla versione che riceve la maggior parte del traffico. Tieni presente quanto segue: Un minimo basso aiuta a mantenere bassi i costi di esecuzione durante i periodi di inattività, ma significa che meno istanze potrebbero essere immediatamente disponibili per rispondere a un picco improvviso del carico. Un minimo elevato consente di preparare l'applicazione per picchi rapidi nel carico delle richieste. App Engine mantiene il numero minimo di istanze in esecuzione per gestire le richieste in entrata. Ti vengono addebitati costi per le istanze, indipendentemente dal fatto che stiano gestendo o meno le richieste. Affinché questa funzionalità funzioni correttamente, devi assicurarti che le richieste di warmup siano abilitate e che la tua applicazione gestisca le richieste di warmup. Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno effetto sulle prestazioni della tua applicazione. Poiché App Engine mantiene riserva le istanze inattive, è improbabile che le richieste entrino nella coda in attesa, ad eccezione di picchi di carico eccezionalmente elevati. Dovrai testare l'applicazione e il volume di traffico previsto per determinare il numero ideale di istanze da riservare. `<min-pending-latency>` Il tempo minimo in secondi che App Engine deve consentire a una richiesta di attendere nella coda in attesa prima di avviare una nuova istanza per gestirla. Specifica un valore compreso tra 0,01 e 15. Un minimo basso significa che le richieste devono trascorrere meno tempo nella coda in attesa quando tutte le istanze esistenti sono attive. Ciò migliora le prestazioni, ma aumenta il costo di esecuzione dell'applicazione. Un minimo elevato significa che le richieste rimarranno in attesa più a lungo se tutte le istanze esistenti sono attive. Questo riduce i costi di esecuzione, ma aumenta il tempo che gli utenti devono attendere per la consegna delle richieste. Esempio <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>F2</instance-class> <automatic-scaling> <target-cpu-utilization>0.65</target-cpu-utilization> <min-instances>5</min-instances> <max-instances>100</max-instances> <max-concurrent-requests>50</max-concurrent-requests> </automatic-scaling> </appengine-web-app>
`<basic-scaling>`	Facoltativo. L'elemento `<basic-scaling>` imposta il numero di istanze per un modulo. Questo elemento può contenere i seguenti elementi: `<idle-timeout>` Facoltativo. L'istanza verrà arrestata questo periodo di tempo dopo aver ricevuto l'ultima richiesta. Il valore predefinito è 5 minuti. `<max-instances>` Obbligatorio. Il numero massimo di istanze che App Engine può creare per questa versione del modulo. Questo è utile per limitare i costi di un modulo. Esempio <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <basic-scaling> <max-instances>11</max-instances> <idle-timeout>10m</idle-timeout> </basic-scaling> </appengine-web-app>
`<manual-scaling>`	Facoltativo. L'elemento `<manual-scaling>` consente la scalabilità manuale di un modulo e imposta il numero di istanze per un modulo. Questo elemento può contenere i seguenti elementi: `<instances>` Il numero di istanze da assegnare al modulo all'inizio. Esempio <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <manual-scaling> <instances>5</instances> </manual-scaling> </appengine-web-app>

<automatic-scaling>

Facoltativo. Se non diversamente specificato, la scalabilità automatica si presume per impostazione predefinita con una classe di istanza predefinita F1.

L'elemento automatic_scaling imposta i livelli minimo e massimo di numero di istanze, latenza e connessioni simultanee per un modulo.

Questo elemento può contenere i seguenti elementi:

<target-cpu-utilization>

Facoltativo. Specifica un valore compreso tra 0,5 e 0,95.

Questo parametro specifica la soglia di utilizzo della CPU al quale le nuove istanze inizieranno a gestire il traffico. In questo modo potrai trovare un equilibrio tra prestazioni e costi, con valori più bassi che aumentano le prestazioni e i costi e i valori più alti diminuiscono le prestazioni, ma anche i costi. Ad esempio, un valore pari a 0,7 indica 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.

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 avvia una nuova istanza.

<max-instances>

Facoltativo. Il numero massimo di istanze che App Engine può creare per questa versione dell'applicazione. Questo è utile per limitare i costi di un modulo. Specifica un valore compreso tra 0 e 2147483647.

<min-instances>

Facoltativo. Il numero minimo di istanze da creare con App Engine 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 richieste 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-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).

Se questa impostazione è troppo elevata, 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.

Nota: se instance-class è impostato su F2 o su un valore superiore, puoi ottimizzare le istanze impostando max-concurrent-requests su un valore superiore a 10, che è il valore predefinito. Per trovare il valore ottimale, aumentalo gradualmente e monitora le prestazioni della tua applicazione.

<max-idle-instances>

Il numero massimo di istanze inattive che App Engine deve mantenere per questa versione. Il valore predefinito è "automatico". 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 delle 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ò compromettere 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 un numero di istanze superiore a quello specificato.

<max-pending-latency>

Il tempo massimo che 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.

Un valore massimo basso significa che App Engine avvia prima nuove istanze per le richieste in attesa, migliorando le prestazioni ma aumentando i costi di esecuzione.
Un massimo elevato significa che gli utenti potrebbero attendere più a lungo per la gestione delle loro richieste, se sono presenti richieste in attesa e nessuna istanza inattiva per gestirle, ma l'esecuzione dell'applicazione avrà un costo inferiore.

<min-idle-instances>

Il numero di istanze da mantenere in esecuzione e pronte per gestire il traffico.Questa impostazione si applica solo alla versione che riceve la maggior parte del traffico. Tieni presente quanto segue:

Un minimo basso aiuta a mantenere bassi i costi di esecuzione durante i periodi di inattività, ma significa che meno istanze potrebbero essere immediatamente disponibili per rispondere a un picco improvviso del carico.
Un minimo elevato consente di preparare l'applicazione per picchi rapidi nel carico delle richieste. App Engine mantiene il numero minimo di istanze in esecuzione per gestire le richieste in entrata. Ti vengono addebitati costi per le istanze, indipendentemente dal fatto che stiano gestendo o meno le richieste. Affinché questa funzionalità funzioni correttamente, devi assicurarti che le richieste di warmup siano abilitate e che la tua applicazione gestisca le richieste di warmup.

Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno effetto sulle prestazioni della tua applicazione. Poiché App Engine mantiene riserva le istanze inattive, è improbabile che le richieste entrino nella coda in attesa, ad eccezione di picchi di carico eccezionalmente elevati. Dovrai testare l'applicazione e il volume di traffico previsto per determinare il numero ideale di istanze da riservare.

<min-pending-latency>

Il tempo minimo in secondi che App Engine deve consentire a una richiesta di attendere nella coda in attesa prima di avviare una nuova istanza per gestirla. Specifica un valore compreso tra 0,01 e 15.

Un minimo basso significa che le richieste devono trascorrere meno tempo nella coda in attesa quando tutte le istanze esistenti sono attive. Ciò migliora le prestazioni, ma aumenta il costo di esecuzione dell'applicazione.
Un minimo elevato significa che le richieste rimarranno in attesa più a lungo se tutte le istanze esistenti sono attive. Questo riduce i costi di esecuzione, ma aumenta il tempo che gli utenti devono attendere per la consegna delle richieste.

Esempio


<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>F2</instance-class>
  <automatic-scaling>
    <target-cpu-utilization>0.65</target-cpu-utilization>
    <min-instances>5</min-instances>
    <max-instances>100</max-instances>
    <max-concurrent-requests>50</max-concurrent-requests>
  </automatic-scaling>
</appengine-web-app>

<basic-scaling>

Facoltativo. L'elemento <basic-scaling> imposta il numero di istanze per un modulo.

Questo elemento può contenere i seguenti elementi:

<idle-timeout>: Facoltativo. L'istanza verrà arrestata questo periodo di tempo dopo aver ricevuto l'ultima richiesta. Il valore predefinito è 5 minuti.
<max-instances>: Obbligatorio. Il numero massimo di istanze che App Engine può creare per questa versione del modulo. Questo è utile per limitare i costi di un modulo.

Esempio


<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>B8</instance-class>
  <basic-scaling>
    <max-instances>11</max-instances>
    <idle-timeout>10m</idle-timeout>
  </basic-scaling>
</appengine-web-app>

<manual-scaling>

Facoltativo. L'elemento <manual-scaling> consente la scalabilità manuale di un modulo e imposta il numero di istanze per un modulo.

Questo elemento può contenere i seguenti elementi:

<instances>: Il numero di istanze da assegnare al modulo all'inizio.

Esempio


<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>B8</instance-class>
  <manual-scaling>
    <instances>5</instances>
  </manual-scaling>
</appengine-web-app>

Gestione temporanea degli elementi

Gran parte del lavoro svolto durante un deployment avviene localmente in una fase di preparazione chiamata gestione temporanea, in cui vengono assemblati i file JAR, vengono compilati i JSP e così via. Facoltativamente, puoi configurare determinate parti del comportamento di gestione temporanea utilizzando elementi nel file di configurazione dell'applicazione. Il deployment della maggior parte delle applicazioni viene eseguito correttamente senza configurare manualmente il comportamento della gestione temporanea. Se non viene eseguito il deployment dell'app, potresti dover configurare la gestione temporanea utilizzando le opzioni mostrate di seguito.

Elemento Descrizione

Elemento	Descrizione
`<staging>`	Facoltativo. Per la maggior parte delle applicazioni non è necessario modificare il comportamento predefinito. L'elemento di gestione temporanea consente di specificare una particolare configurazione temporanea, se necessario per il deployment. Questo elemento può contenere i seguenti elementi: `<enable-jar-splitting>` Facoltativo. Suddividi i file jar di grandi dimensioni (> 10 megabyte) in frammenti più piccoli. (valore predefinito: true). `<jar-splitting-excludes>` Specifica un elenco separato da virgole di suffissi di file. Se `enable-jar-splitting` è abilitato, tutti i file che corrispondono ai suffissi verranno esclusi da tutti i JAR. `<disable_jar_jsps>` Non classi jar generate da JSP. (valore predefinito: false). `<enable-jar-classes>` Pubblica i contenuti di WEB-INF/classi. (valore predefinito: true). `<delete-jsps>` Elimina i file di origine JSP dopo la compilazione. (valore predefinito: true). `<compile-encoding>` Codifica di input dei file di origine per la compilazione. (predefinito: utf-8). Ad esempio: <staging> <delete-jsps>false</delete-jsps> </staging>

<staging>

Facoltativo. Per la maggior parte delle applicazioni non è necessario modificare il comportamento predefinito.

L'elemento di gestione temporanea consente di specificare una particolare configurazione temporanea, se necessario per il deployment.

Questo elemento può contenere i seguenti elementi:

<enable-jar-splitting>: Facoltativo. Suddividi i file jar di grandi dimensioni (> 10 megabyte) in frammenti più piccoli. (valore predefinito: true).
<jar-splitting-excludes>: Specifica un elenco separato da virgole di suffissi di file. Se enable-jar-splitting è abilitato, tutti i file che corrispondono ai suffissi verranno esclusi da tutti i JAR.
<disable_jar_jsps>: Non classi jar generate da JSP. (valore predefinito: false).
<enable-jar-classes>: Pubblica i contenuti di WEB-INF/classi. (valore predefinito: true).
<delete-jsps>: Elimina i file di origine JSP dopo la compilazione. (valore predefinito: true).
<compile-encoding>: Codifica di input dei file di origine per la compilazione. (predefinito: utf-8).

Ad esempio:


        <staging>
          <delete-jsps>false</delete-jsps>
        </staging>

Valore predefinito dell'opzione temporanea

I valori predefiniti per le opzioni di gestione temporanea variano a seconda che utilizzi gli strumenti basati su Google Cloud SDK, ad esempio gcloud CLI o i plug-in Maven, Gradle, Eclipse o IntelliJ basati su Google Cloud SDK.

Elemento temporaneo	Valori predefiniti basati sull'SDK di App Engine	Valori predefiniti basati su Google Cloud SDK
`enable-jar-splitting`	`false`	`true`
`jar-splitting-excludes`	NA	NA
`disable-jar-jsps`	`false`	`false`
`enable-jar-classes`	`false`	`true`. Questo può influire sull'ordine di caricamento della classe, quindi se la tua app dipende da un determinato ordine che utilizza la precedente impostazione predefinita di `false`, puoi impostarlo su `false`.
`delete-jsps`	`false`	`true`
`compile-encoding`	`utf-8`	`utf-8`

Includi ed escludi la sintassi

I pattern del percorso vengono specificati utilizzando zero o più elementi <include> e <exclude>. In un pattern, '*' rappresenta zero o più caratteri nel nome di un file o di una directory, mentre ** rappresenta zero o più directory in un percorso. I file e le directory che corrispondono ai pattern <exclude> non verranno caricati quando esegui il deployment dell'app in App Engine. Tuttavia, questi file e directory saranno ancora accessibili all'applicazione se viene eseguita sul server di sviluppo locale.

Un elemento <include> sostituisce il comportamento predefinito di inclusione di tutti i file. Un elemento <exclude> si applica dopo tutti i pattern <include> (nonché il valore predefinito se non viene fornito alcun elemento <include> esplicito).

L'esempio seguente mostra come designare tutti i file .png come file statici (tranne quelli nella directory data/ e in tutte le relative sottodirectory):

<static-files>
  <include path="/**.png" />
  <exclude path="/data/**.png" />
</static-files>

Puoi inoltre impostare le intestazioni HTTP da utilizzare quando rispondi alle richieste a queste risorse statiche.

<static-files>
  <include path="/my_static-files" >
    <http-header name="Access-Control-Allow-Origin"
                 value="http://example.org" />
  </include>
</static-files>

Tipi MIME per i file statici

Per impostazione predefinita, i file statici vengono pubblicati utilizzando un tipo MIME selezionato in base all'estensione del nome file. Puoi associare tipi MIME personalizzati a estensioni di nomi file per i file statici utilizzando gli elementi mime-mapping in web.xml.

Timeout URLFetch

Puoi impostare una scadenza per ogni richiesta URLFetch. Per impostazione predefinita, la scadenza per un recupero è di 5 secondi. Puoi modificare questa impostazione predefinita includendo la seguente impostazione nel file di configurazione di appengine-web.xml. Specifica il timeout in secondi:

<system-properties>
    <property name="appengine.api.urlfetch.defaultDeadline" value="10"/>
</system-properties>