Questa pagina è stata tradotta dall'API Cloud Translation.

Riferimento appengine-web.xml

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province 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.

Il file appengine-web.xml deve essere usato soltanto per configurare l'app se stai eseguendo la migrazione di un'app esistente dal runtime Java 8 di App Engine alla l'ultima versione di Java supportata e vuoi utilizzare i servizi in bundle legacy. Se utilizzi appengine-web.xml nel tuo progetto, app.yaml è generate automaticamente al momento del deployment.

Le applicazioni Java di App Engine utilizzano un file di configurazione, denominato appengine-web.xml, di specificare informazioni sulla tua app e identificare quali file I file WAR sono file statici (come le immagini) e che sono file di risorse utilizzati per l'applicazione.

Sintassi

Un'app Java di App Engine deve avere un file denominato appengine-web.xml nel WAR, nella directory WEB-INF/. Si tratta di 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 è obbligatorio se esegui il deployment dell'app utilizzando una piattaforma basata su Google Cloud SDK come il comando `gcloud app deploy`, IntelliJ o Eclipse, Maven o Gradle. La Gli strumenti basati su Google Cloud SDK ignorano questo elemento e recupera l'ID progetto dalla proprietà progetto gcloud config. Tieni presente che anche se puoi eseguire l'override dell'ID progetto utilizzando strumento a riga di comando, imposta un ID progetto a livello di macchina, creare confusione se stai sviluppando più progetti. L'elemento `<application>` contiene l'ID progetto dell'applicazione. Si tratta dell'ID progetto che registri quando crei il 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 del comando di processo che avvia l'applicazione Java. Per impostazione predefinita, il punto di accesso generato per una classe di istanze F4 (le impostazioni della memoria vengono calcolate dalla classe di istanze) è equivalente 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 altri flag del processo JVM o definire il tuo processo da avviare. Tieni presente che il deployment dell'applicazione viene eseguito nella directory `/workspace`, mentre i JAR del runtime si trovano nella directory `/base/java_runtime`. Scopri come personalizzare il punto di contatto per il runtime Java utilizzando le variabili di ambiente.
`<async-session-persistence>`	Facoltativo. È possibile ridurre la latenza delle richieste configurando per scrivere in modo asincrono i dati di sessione HTTP datastore: <async-session-persistence enabled="true" /> Se la persistenza della sessione asincrona è attiva, App Engine invierà 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 desideri se preferisci usare una coda diversa, aggiungi l'attributo "queue-name": <async-session-persistence enabled="true" queue-name="myqueue"/> I dati di sessione vengono sempre scritti in modo sincrono in memcache. Se una richiesta tenta di leggere i dati della sessione quando memcache non è disponibile (o se i dati della sessione sono stati svuotati), verrà eseguito il failover su Datastore, che potrebbe non avere ancora i dati della sessione più recenti. Ciò significa che la persistenza della sessione asincrona può causare la visualizzazione di dati устаревших della sessione da parte della tua applicazione. 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 delle entità, puoi modificare il metodo impiegato impostando il criterio di ID automatico. Di seguito sono riportate le opzioni valide: `default` Predefinita. Utilizza ID automatici sparsi che sono grandi e ben distribuiti numeri interi sufficientemente piccoli da essere rappresentati da numeri in virgola mobile a 64 bit. `legacy` L'opzione precedente verrà ritirata in una versione futura e verrà rimosso. Per ulteriori informazioni, consulta il post del blog che annuncia questa modifica.
`<automatic-scaling>`	Facoltativo. Per una spiegazione completa, consulta la sezione sulla scalabilità automatica.
`<basic-scaling>`	Facoltativo. Per una spiegazione completa, consulta la sezione sulla scalabilità di base.
`<env-variables>`	Facoltativo. Il file `appengine-web.xml` può definire le variabili di ambiente 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 in base a questo file e richiede che nell'ambiente locale queste variabili siano già impostate su valori corrispondenti. export DEFAULT_ENCODING="UTF-8" dev_appserver war Quando viene eseguito il deployment in App Engine, l'ambiente viene creato con queste variabili già impostate.
`<inbound-services>`	Facoltativo. Prima che un'applicazione possa ricevere email, l'applicazione deve essere configurata per abilitare il servizio. Per attivare il servizio per un'app Java, includi una sezione `<inbound-services>` nel `appengine-web.xml` file. È disponibile il seguente servizio in entrata: `mail` Consente all'applicazione di ricevere posta.
`<instance-class>`	Facoltativo. Le dimensioni della classe di istanza per questo modulo. Le seguenti classi di istanze sono disponibili quando specifichi opzioni di scalabilità diverse: `automatic_scaling` Quando si utilizza la scalabilità automatica, F1, F2, F4 e F4_1G sono disponibili classi di istanza. Valore predefinito: F1 viene assegnato se non specifichi una classe di istanza insieme all'elemento `automatic_scaling`. `basic_scaling` Quando utilizzi la scalabilità di base, sono disponibili le classi di istanze B1, B2, B4, B4_1G e B8. Valore predefinito: B2 viene assegnato se non specifichi una classe di istanza insieme all'elemento `basic_scaling`. `manual_scaling` Quando si utilizza la scalabilità manuale, B1, B2, B4, B4_1G e B8 sono disponibili classi di istanza. Valore predefinito: B2 viene assegnato 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, che è il valore predefinito. Per trovare il valore ottimale, aumentalo gradualmente e monitora il rendimento del un'applicazione.
`<manual-scaling>`	Facoltativo. Per una spiegazione completa, consulta la sezione relativa alla scalabilità manuale.
`<precompilation-enabled>`	Facoltativo. App Engine utilizza una "precompilazione" con il bytecode Java un'app per migliorare le prestazioni dell'app nel runtime Java completamente gestito di Google Cloud. Il codice precompilato funziona in modo identico all'originale in bytecode. Se per qualche motivo preferisci che la tua app non utilizzi la precompilazione, puoi disattivarla aggiungendo quanto segue al `appengine-web.xml` file: <precompilation-enabled>false</precompilation-enabled>
`<module>`	Nota: ora i moduli si chiamano Servizi e i servizi sono ancora dichiarati nei file `appengine-web.xml` come moduli, ad esempio: `<module>service_name</module>`. Obbligatorio se si crea un servizio. Facoltativo per il servizio predefinito. Ogni servizio e ogni versione deve avere un nome. Un nome può contenere numeri, lettere e trattini. Non può essere più lungo di 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 all'interno della tua applicazione che contiene i file statici dell'applicazione. Quando viene inviata una richiesta per un file statico, viene creato il `<public-root>` applicazione è anteposta al percorso di richiesta. Questo fornisce il percorso un file dell'applicazione contenente i contenuti richiesti. Il valore predefinito di `<public-root>` è `/`. Ad esempio, di seguito viene mappato il percorso dell'URL `/index.html` al percorso file dell'applicazione `/static/index.html`: <public-root>/static</public-root>
`<resource-files>`	Facoltativo. I file elencati nell'elemento `<resource-files>` sono accessibili al codice dell'applicazione tramite il file system. Questi file vengono archiviati tra i server delle applicazioni e l'app, anziché il modo in cui i file statici vengono archiviati e pubblicati. L'elemento `<resource-files>` può contenere i seguenti elementi: `<include>` Un elemento `<include>` indica che i file sono file di risorse e sono disponibili per il codice dell'applicazione. Questi file sono disponibili per il tuo codice solo in modalità di sola lettura e non per la pubblicazione di traffico. Inclusione ed esclusione di file. `<exclude>` I file e le directory corrispondenti ai pattern `<exclude>` non verranno caricati o resi disponibili per il codice dell'applicazione. Tuttavia, questi file e queste directory saranno ancora accessibili alla tua applicazione quando viene eseguita sul Development Server locale. Per ulteriori informazioni, vedi 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, tranne quelli nella directory `feeds/` e in tutte le relative sottodirectory. I file di risorse di App Engine vengono letti utilizzando `java.io.File` o `javax.servlet.ServletContext.getResource/getResourceAsStream`. Non sono accessibili tramite `Class.getResourceAsStream()`.
`<runtime>`	Per utilizzare la versione Java supportata più recente, devi specificare questa voce con il valore `java21`. Esempio: <runtime>java21</runtime>
`<service>`	I servizi erano precedentemente noti come moduli. Attualmente, la definizione di un servizio come: `<service>service_name</service >` è supportato solo da gcloud app tramite comandi SQL.
`<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 delle sessioni servlet. L'implementazione archivia i dati di sessione in Datastore per persistenza e usa anche memcache per migliorare la velocità. Come per la maggior parte degli altri contenitori di servlet, gli attributi della sessione impostati con "session.setAttribute()" durante la richiesta vengono mantenuti alla fine della richiesta. Questa funzionalità è disattivata per impostazione predefinita. Per attivarla, aggiungi quanto segue a `appengine-web.xml`: Esempio: <sessions-enabled>true</sessions-enabled> L'implementazione crea entità Datastore di tipo `_ah_SESSION` e voci memcache utilizzando chiavi con un prefisso `_ahs`. Puoi eliminare queste entità utilizzando modello Dataflow. Nota: poiché App Engine archivia i dati della sessione in Datastore e memcache, tutti i valori memorizzati nella sessione devono implementare l'interfaccia `java.io.Serializable`. Vedi Elemento `async-session-persistence` per ridurre il latenza di archiviazione dei dati di sessione.
`<ssl-enabled>`	Facoltativo. Per impostazione predefinita, qualsiasi utente può accedere a qualsiasi URL utilizzando HTTP o HTTPS. Puoi configurare un'app in modo che richieda HTTPS per determinati URL nel descrittore di deployment. Consulta Descrittore di deployment: URL sicuri. Se vuoi impedire l'utilizzo di HTTPS per l'applicazione, metti il nel file `appengine-web.xml`: <ssl-enabled>false</ssl-enabled> Non è possibile 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 mostra una pagina di errore generica. Puoi configurare l'app in modo che pubblichi un file statico personalizzato di queste pagine di errore generiche, purché i dati di errore personalizzati siano inferiori di oltre 10 kilobyte. Puoi configurare diversi file statici da pubblicare di ciascun codice di errore supportato specificando i file nella `appengine-web.xml`. Per pubblicare pagine di errore personalizzate, aggiungi una sezione `<static-error-handlers>` a `appengine-web.xml`, come nell'esempio seguente: <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 agli errori non si sovrapponga ai percorsi dei gestori di file statici. Ogni voce `file` indica un file statico da caricare al posto della risposta generica all'errore. `error-code` indica il codice di errore che deve causare la pubblicazione del file associato. I codici di errore supportati sono i seguenti: `over_quota` Indica che l'app ha superato il limite una quota di risorse. `timeout` Viene pubblicato se viene raggiunta una scadenza prima di ricevere una risposta da parte del tuo dell'app. Il campo `error-code` è facoltativo; Se non è specificato, dato file è la risposta di errore predefinita per la tua app. Facoltativamente, puoi specificare un `mime-type` da utilizzare quando e restituire l'errore personalizzato. Consulta l'elenco completo dei tipi MIME.
`<static-files>`	Facoltativo. L'elemento `<static-files>` specifica i pattern che trovare la corrispondenza dei percorsi di file da includere ed escludere dall'elenco dei file statici; l'override o la modifica del comportamento predefinito. I file statici vengono pubblicati da server e cache dedicati separati dai server delle applicazioni e sono utili per pubblicare 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 valore predefinito il comportamento di inclusione di tutti i file non JSP. L'elemento `<include>` può specificare le intestazioni HTTP da utilizzare per rispondere alle richieste per le risorse specificate. Per ulteriori informazioni, consulta Includi ed escludi i file. Puoi ignorare la scadenza della cache statica predefinita 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 ulteriori informazioni, consulta la sezione Scadenza della cache. `<exclude>` File e directory corrispondenti a `<exclude>` i pattern non verranno caricati quando esegui il deployment dell'app in App Engine. Tuttavia, questi file e queste directory saranno comunque accessibili alla tua applicazione quando viene eseguita sul server di sviluppo locale. Per ulteriori informazioni, vedi Inclusione ed esclusione 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 proprietà del sistema e 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> Facoltativo. Puoi configurare un connettore HTTP per migliorare la CPU dell'utilizzo della memoria. <system-properties> <property name="appengine.use.httpconnector" value="true"/> </system-properties> A partire da Java 21, puoi configurare il server web Java in modo che utilizzi thread virtuali. Ad esempio: <system-properties> <property name="appengine.use.virtualthreads" value="true"/> </system-properties> Per ulteriori informazioni sul supporto dei thread, consulta Jetty 12 - Supporto per i 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 attivare la fatturazione per la tua app, altrimenti riceverai eccezioni, descritte nella sezione Inviare richieste. 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 la versione di accesso all'ultima versione del codice dell'app. L'identificatore della 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 delle versioni devono iniziare con una lettera, per distinguerli dalle numeriche che sono sempre specificate da un numero. In questo modo viene evitata l'ambiguità con URL come `123.my-module.uc.r.appspot.com`, che possono essere interpretati in due modi: se esiste la versione "123", il target sarà la versione "123" del modulo in questione. Se la versione non esiste, il target sarà il numero dell'istanza 123 della versione predefinita del in maggior dettaglio più avanti in questo modulo.
`<warmup-requests-enabled>`	Facoltativo. Valore predefinito: true. Le richieste di riscaldamento sono abilitate per impostazione predefinita applicazioni Java. Con le richieste di warmup abilitate, l'infrastruttura di App Engine emette il messaggio "GET" richieste a `/_ah/warmup`, inizializzazione in corso `<load-on-startup>` servlet, `ServletContextListeners` e servlet di riscaldamento personalizzati, che consentono di inizializzare il codice dell'applicazione in base alle esigenze. Potrebbe essere necessario implementare il tuo gestore `/_ah/warmup` a seconda di quale di questi metodi scegliere. Per disattivare le richieste di warmup, specifica `false` per questo elemento: <warmup-requests-enabled>false</warmup-requests-enabled>
`<vpc-access-connector>`	Facoltativo. Configura la tua applicazione per l'uso di un accesso VPC serverless il connettore dati, consentendo all'applicazione di inviare richieste delle tue risorse 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 ulteriori informazioni, vedi Connessione a risorse interne in una rete VPC.

Ridimensionare gli elementi

La tabella seguente elenca le opzioni per definire in che modo puoi specificare la scalabilità della tua applicazione.

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

Elemento Descrizione

Elemento	Descrizione
`<automatic-scaling>`	Facoltativo. La scalabilità automatica viene utilizzata per impostazione predefinita con un dell'istanza di `F1`, se non diversamente specificato. L'elemento `automatic_scaling` imposta un valore minimo e massimo livelli per numero di istanze, latenza e connessioni simultanee per un modulo. Questo elemento può contenere i seguenti elementi: `<target-cpu-utilization>` Facoltativa. Specifica un valore compreso tra 0,5 e 0,95. Questo parametro specifica la soglia di utilizzo della CPU a cui verranno avviate nuove istanze per gestire il traffico, consentendoti di trovare il giusto equilibrio tra prestazioni e costi: i valori più bassi aumentano le prestazioni e i costi, mentre i valori più elevati riducono le prestazioni, ma anche i costi. Ad esempio, un valore di 0,7 indica che le nuove istanze verranno avviate quando l'utilizzo della CPU raggiunge il 70%. `<target-throughput-utilization>` Facoltativa. 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 concorrenti. Quando di richieste in parallelo raggiunge un valore uguale a `max-concurrent-requests` volte `target-throughput-utilization`, lo scheduler avvia una nuova istanza. `<max-instances>` Facoltativa. Il numero massimo di istanze che App Engine può creare per questa versione dell'applicazione. Questa operazione è utile per limitare i costi di un modulo. Specifica un valore compreso tra 0 e 2147483647. `<min-instances>` Facoltativa. Il numero minimo di istanze da creare da App Engine per questa versione del modulo. Queste istanze gestiscono il traffico quando e continuano a gestire il traffico anche e le istanze aggiuntive avviate 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 il ridimensionamento a 0 istanze al fine di ridurre i costi quando non vengono inviate richieste. Tieni presente che ti viene addebitato il costo per il numero di istanze specificate, indipendentemente dal fatto che ricevano o meno traffico. `<max-concurrent-requests>` Facoltativo. Il numero di richieste in parallelo che un'istanza con scalabilità automatica può accettare prima che lo scheduler generi una nuova istanza (valore predefinito: 10, massimo: 80). Se questa impostazione fosse troppo flessibile, potresti riscontrare una maggiore latenza dell'API alto. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima viene raggiunto il numero massimo effettivo di richieste. Nota: se `instance-class` sia impostato su `F2` o su un valore superiore, puoi ottimizzare le istanze impostando `max-concurrent-requests` a un valore superiore a 10, che è il valore predefinito. Per trovare il valore ottimale, aumentalo gradualmente e monitora il rendimento della tua applicazione. `<max-idle-instances>` Il numero massimo di istanze inattive che App Engine dovrebbe per questa versione. Il valore predefinito è "automatico". 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 tali 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: quando si torna ai livelli normali dopo un picco di carico, il numero di istanze inattive può superare temporaneamente il valore massimo specificato. Tuttavia, non ti verrà addebitato il costo di più istanze rispetto al numero massimo specificato. `<max-pending-latency>` Il tempo massimo che App Engine deve consentire a una richiesta di rimanere in coda in attesa prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre la latenza in attesa. Un valore massimo basso significa che App Engine avvierà prima le nuove istanze per le richieste in attesa, migliorando le prestazioni ma aumentando la pubblicazione costi aggiuntivi. Un valore massimo elevato significa che gli utenti potrebbero dover attendere più a lungo per la pubblicazione delle loro richieste, se ci sono richieste in attesa e non sono disponibili istanze inattive per gestirle, ma il costo di esecuzione della tua applicazione sarà inferiore. `<min-idle-instances>` Il numero di istanze da mantenere in esecuzione e pronte a gestire il traffico. Questa impostazione si applica solo alla versione che riceve la maggior parte del traffico. Tieni presente quanto segue: Un numero minimo ridotto consente di ridurre i costi di gestione durante i periodi di inattività, ma significa che potrebbero essere disponibili meno istanze immediatamente per rispondere a un picco di carico improvviso. Un minimo elevato ti consente di preparare l'applicazione dei picchi nel carico delle richieste. App Engine mantiene il numero minimo di in esecuzione per gestire le richieste in entrata. Ti vengono addebitati costi per le istanze, indipendentemente dal fatto che gestiscano o meno le richieste. Affinché questa funzione funzioni correttamente, devi assicurarti che richieste di riscaldamento siano abilitate e che la tua applicazione e gestisce le richieste di warmup. Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno impatto sulle prestazioni della tua applicazione. Poiché App Engine mantiene di riserva le istanze inattive, è improbabile che le richieste entrino nella coda In attesa se non in picchi di carico eccezionalmente elevati. Dovrai testare dell'applicazione e del volume di traffico previsto per determinare di istanze da mantenere come riserva. `<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 valore minimo basso significa che le richieste devono trascorrere meno tempo nella coda in attesa quando tutte le istanze esistenti sono attive. In questo modo, vengono migliorate le prestazioni, ma aumenta il costo di esecuzione dell'applicazione. Un minimo elevato indica che le richieste rimarranno in attesa più a lungo se tutte sono attive. Ciò riduce i costi di gestione, aumenta il tempo di attesa da parte degli utenti prima che le richieste vengano gestito. 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 di Compute Engine per un modulo. Questo elemento può contenere i seguenti elementi: `<idle-timeout>` Facoltativo. L'istanza verrà arrestata per questo periodo di tempo dopo che riceve l'ultima richiesta. Il valore predefinito è 5 minuti. `<max-instances>` Obbligatorio. Il numero massimo di istanze che App Engine deve creare per questa versione del modulo. Questa operazione è 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 per 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. La scalabilità automatica viene utilizzata per impostazione predefinita con un dell'istanza di F1, se non diversamente specificato.

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

Questo elemento può contenere i seguenti elementi:

<target-cpu-utilization>

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

Questo parametro specifica la soglia di utilizzo della CPU a cui verranno avviate nuove istanze per gestire il traffico, consentendoti di trovare il giusto equilibrio tra prestazioni e costi: i valori più bassi aumentano le prestazioni e i costi, mentre i valori più elevati riducono le prestazioni, ma anche i costi. Ad esempio, un valore di 0,7 indica che le nuove istanze verranno avviate quando l'utilizzo della CPU raggiunge il 70%.

<target-throughput-utilization>

Facoltativa. 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 concorrenti. Quando di richieste in parallelo raggiunge un valore uguale a max-concurrent-requests volte target-throughput-utilization, lo scheduler avvia una nuova istanza.

<max-instances>

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

<min-instances>

Facoltativa. Il numero minimo di istanze da creare da App Engine per questa versione del modulo. Queste istanze gestiscono il traffico quando e continuano a gestire il traffico anche e le istanze aggiuntive avviate 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 il ridimensionamento a 0 istanze al fine di ridurre i costi quando non vengono inviate richieste. Tieni presente che ti viene addebitato il costo per il numero di istanze specificate, indipendentemente dal fatto che ricevano o meno traffico.

<max-concurrent-requests>

Facoltativo. Il numero di richieste in parallelo che un'istanza con scalabilità automatica può accettare prima che lo scheduler generi una nuova istanza (valore predefinito: 10, massimo: 80).

Se questa impostazione fosse troppo flessibile, potresti riscontrare una maggiore latenza dell'API alto. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima viene raggiunto il numero massimo effettivo di richieste.

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

<max-idle-instances>

Il numero massimo di istanze inattive che App Engine dovrebbe per questa versione. Il valore predefinito è "automatico". 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 tali 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: quando si torna ai livelli normali dopo un picco di carico, il numero di istanze inattive può superare temporaneamente il valore massimo specificato. Tuttavia, non ti verrà addebitato il costo di più istanze rispetto al numero massimo specificato.

<max-pending-latency>

Il tempo massimo che App Engine deve consentire a una richiesta di rimanere in coda in attesa prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre la latenza in attesa.

Un valore massimo basso significa che App Engine avvierà prima le nuove istanze per le richieste in attesa, migliorando le prestazioni ma aumentando la pubblicazione costi aggiuntivi.
Un valore massimo elevato significa che gli utenti potrebbero dover attendere più a lungo per la pubblicazione delle loro richieste, se ci sono richieste in attesa e non sono disponibili istanze inattive per gestirle, ma il costo di esecuzione della tua applicazione sarà inferiore.

<min-idle-instances>

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

Un numero minimo ridotto consente di ridurre i costi di gestione durante i periodi di inattività, ma significa che potrebbero essere disponibili meno istanze immediatamente per rispondere a un picco di carico improvviso.
Un minimo elevato ti consente di preparare l'applicazione dei picchi nel carico delle richieste. App Engine mantiene il numero minimo di in esecuzione per gestire le richieste in entrata. Ti vengono addebitati costi per le istanze, indipendentemente dal fatto che gestiscano o meno le richieste. Affinché questa funzione funzioni correttamente, devi assicurarti che richieste di riscaldamento siano abilitate e che la tua applicazione e gestisce le richieste di warmup.

Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno impatto sulle prestazioni della tua applicazione. Poiché App Engine mantiene di riserva le istanze inattive, è improbabile che le richieste entrino nella coda In attesa se non in picchi di carico eccezionalmente elevati. Dovrai testare dell'applicazione e del volume di traffico previsto per determinare di istanze da mantenere come riserva.

<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 valore minimo basso significa che le richieste devono trascorrere meno tempo nella coda in attesa quando tutte le istanze esistenti sono attive. In questo modo, vengono migliorate le prestazioni, ma aumenta il costo di esecuzione dell'applicazione.
Un minimo elevato indica che le richieste rimarranno in attesa più a lungo se tutte sono attive. Ciò riduce i costi di gestione, aumenta il tempo di attesa da parte degli utenti prima che le richieste vengano gestito.

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 di Compute Engine per un modulo.

Questo elemento può contenere i seguenti elementi:

<idle-timeout>: Facoltativo. L'istanza verrà arrestata per questo periodo di tempo dopo che riceve l'ultima richiesta. Il valore predefinito è 5 minuti.
<max-instances>: Obbligatorio. Il numero massimo di istanze che App Engine deve creare per questa versione del modulo. Questa operazione è 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 per 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>

Elementi di gestione temporanea

Gran parte del lavoro svolto durante un deployment avviene localmente in un passaggio di preparazione chiamato staging, in cui i file JAR vengono assemblati, le JSP vengono compilate e così via. Facoltativamente, puoi configurare alcune parti della gestione temporanea il comportamento dell'utente usando elementi temporanei nel file di configurazione dell'applicazione. Più alta il deployment delle applicazioni verrà eseguito correttamente senza configurare manualmente la gestione temporanea comportamento degli utenti. Se l'app non viene dispiata, potrebbe essere necessario configurare lo staging utilizzando le opzioni mostrate di seguito.

Elemento Descrizione

Elemento	Descrizione
`<staging>`	Facoltativo. La maggior parte delle applicazioni non ha bisogno di modificare il comportamento predefinito. L'elemento di staging consente di specificare una determinata configurazione di staging se necessaria 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 di suffissi di file separati da virgole. Se `enable-jar-splitting` è abilitato, tutti i file che corrispondono ai suffissi verranno esclusi da tutti i JAR. `<disable_jar_jsps>` Non utilizzare le classi jar generate da JSP. (valore predefinito: false). `<enable-jar-classes>` Esegui il jar dei contenuti di WEB-INF/classes. (valore predefinito: true). `<delete-jsps>` Elimina i file di origine JSP dopo la compilazione. (valore predefinito: true). `<compile-encoding>` Codifica di input dei file sorgente per la compilazione. (valore predefinito: utf-8). Ad esempio: <staging> <delete-jsps>false</delete-jsps> </staging>

<staging>

Facoltativo. La maggior parte delle applicazioni non ha bisogno di modificare il comportamento predefinito.

L'elemento di staging consente di specificare una determinata configurazione di staging se necessaria 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 di suffissi di file separati da virgole. Se enable-jar-splitting è abilitato, tutti i file che corrispondono ai suffissi verranno esclusi da tutti i JAR.
<disable_jar_jsps>: Non utilizzare le classi jar generate da JSP. (valore predefinito: false).
<enable-jar-classes>: Esegui il jar dei contenuti di WEB-INF/classes. (valore predefinito: true).
<delete-jsps>: Elimina i file di origine JSP dopo la compilazione. (valore predefinito: true).
<compile-encoding>: Codifica di input dei file sorgente per la compilazione. (valore predefinito: utf-8).

Ad esempio:

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

Valori predefiniti delle opzioni di gestione temporanea

I valori predefiniti per le opzioni di gestione temporanea sono diversi a seconda che utilizzi o meno Strumenti basati su Google Cloud SDK, come gcloud CLI, o Basato su Google Cloud SDK Maven Gradle Plug-in Eclipse o IntelliJ.

Elemento temporaneo	Valori predefiniti basati su SDK App Engine -	Impostazioni predefinite basate su Google Cloud SDK
`enable-jar-splitting`	`false`	`true`
`jar-splitting-excludes`	NA	NA
`disable-jar-jsps`	`false`	`false`
`enable-jar-classes`	`false`	`true`. Ciò può influire sull'ordine di caricamento delle classi, pertanto se la tua app dipende da un determinato ordine che utilizza il valore predefinito precedente `false`, puoi impostarlo su `false`.
`delete-jsps`	`false`	`true`
`compile-encoding`	`utf-8`	`utf-8`

Sintassi di inclusione ed esclusione

I pattern di percorso vengono specificati utilizzando zero o più <include> e Elementi <exclude>. In un pattern, '*' rappresenta zero o più caratteri di qualsiasi tipo nel nome di un file o di una directory e ** rappresenta zero o più directory in un percorso. I file e le directory corrispondenti ai pattern <exclude> non verranno caricati quando esegui il deployment dell'app in App Engine. Tuttavia, questi file e queste directory saranno comunque accessibili alla tua applicazione quando vengono eseguiti sul server di sviluppo locale.

Un elemento <include> sostituisce il comportamento predefinito di inclusione di tutti i file. Dopo tutto, viene applicato un elemento <exclude> Pattern <include> (oltre a quello predefinito se non sono presenti <include> è specificato).

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

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

Puoi anche impostare le intestazioni HTTP da utilizzare per rispondere 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 al nome file per i file statici che utilizzano 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 di configurazione di appengine-web.xml. Specifica il timeout in secondi:

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