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 al momento della creazione dell'app. Il codice non corrispondono a un paese o a una provincia, anche se potrebbero essere visualizzati alcuni ID regione in modo simile ai codici paese e provincia di uso comune. Per le app create dopo il giorno Febbraio 2020, REGION_ID.r è incluso in URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.

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 Crea il tuo progetto nella console Google Cloud.
`<app-engine-apis>`	Facoltativo. Se vuoi utilizzare Servizi legacy in bundle di App Engine per 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 valore per una classe di istanza F4 (le impostazioni della memoria vengono calcolate della 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 il tuo processo per l'avvio. 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 ingresso 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" /> Con la persistenza della sessione asincrona attivata, App Engine invia un'attività della coda di attività per scrivere i dati della sessione nel datastore prima scrivere i dati 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 prova a leggere i dati della sessione quando memcache non è disponibile (o i dati della sessione sono stati cancellati), il failover verrà eseguito in Datastore, che potrebbero non disporre ancora dei dati più recenti. Questo significa che la persistenza della sessione asincrona può causare per visualizzare dati di sessione inattivi. Tuttavia, per la maggior parte delle applicazioni la latenza beneficio supera di gran lunga il rischio.
`<auto-id-policy>`	Facoltativo. Se sei impostazione automatica degli identificatori di entità, puoi modificare il metodo per impostare il criterio ID automatico. Di seguito sono riportate alcune 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, leggi il post del blog in cui viene presentato modifica.
`<automatic-scaling>`	Facoltativo. Per una spiegazione completa, consulta la sezione sulla scalabilità automatica .
`<basic-scaling>`	Facoltativo. Per una spiegazione completa, consulta la sezione 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 il tuo ambiente locale, il server di sviluppo non imposta le variabili di ambiente in base a questo file e richiede in cui l'ambiente locale abbia già impostato queste variabili valori corrispondenti. export DEFAULT_ENCODING="UTF-8" dev_appserver war Quando viene eseguito il deployment in App Engine, l'ambiente viene creato sono già impostate.
`<inbound-services>`	Facoltativo. Prima che un'applicazione possa ricevere email, l'applicazione deve essere configurata per abilitare il servizio. Per abilitare il servizio per un'app Java, devi includere un'istanza Sezione `<inbound-services>` nel `appengine-web.xml` file. È disponibile il seguente servizio in entrata: `mail` Consente alla tua 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 diverse opzioni di scalabilità: `automatic_scaling` Quando si utilizza la scalabilità automatica, F1, F2, F4 e F4_1G sono disponibili classi di istanza. Predefinito:F1 viene assegnato se non specifichi un instance insieme alla classe `automatic_scaling`. `basic_scaling` Quando si utilizza la scalabilità di base, le istanze B1, B2, B4, B4_1G e B8 corsi. Predefinito: B2 viene assegnato se non specifichi un instance insieme alla classe `basic_scaling`. `manual_scaling` Quando si utilizza la scalabilità manuale, B1, B2, B4, B4_1G e B8 sono disponibili classi di istanza. Predefinito: B2 viene assegnato se non specifichi un instance insieme alla classe `manual_scaling`. Nota: se `instance-class` sia impostato su `F2` o su un valore superiore, puoi ottimizzare le istanze impostando `max-concurrent-requests` maggiore di 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 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 alle File `appengine-web.xml`: <precompilation-enabled>false</precompilation-enabled>
`<module>`	Nota: i moduli sono ora denominati Servizi e i servizi sono ancora dichiarati in `appengine-web.xml` file 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ò contenere più di 63 caratteri, iniziano o terminano con un trattino e contengono stringa "-dot". Scegli un nome univoco per ogni servizio e ogni completamente gestita. Non riutilizzare i nomi tra servizi e versioni. Vedi anche servizio.
`<public-root>`	Facoltativo. `<public-root>` è una directory della tua applicazione che contiene i file statici per la tua 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 nel L'elemento `<resource-files>` è accessibile utilizzando 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>` designa i file come di risorse e disponibili per il codice dell'applicazione. Questi file sono disponibili per il codice solo in sola lettura e non per gestione del traffico. Inclusione ed esclusione di file. `<exclude>` File e directory corrispondenti a `<exclude>` i pattern non verranno caricati o non saranno disponibili per la tua applicazione le API nel tuo codice. Tuttavia, questi file e directory continueranno a essere accessibile alla tua applicazione quando viene eseguita di sviluppo. 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 `.xml` come file di risorse, ad eccezione di quelli in `feeds/` e tutte le sue 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 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 >` è supportato solo da gcloud app tramite comandi SQL.
`<service-account>`	Facoltativo. L'elemento `<service-account>` ti consente di specificare account di servizio gestito dall'utente come identità per la versione. L'account di servizio specificato durante l'accesso ad altri servizi Google Cloud ed l'esecuzione di 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 con la maggior parte degli altri servlet container, gli attributi di sessione impostati con "session.setAttribute()" durante la richiesta sono mantenuti al termine 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 del tipo `_ah_SESSION` e voci memcache utilizzando chiavi con un prefisso di `_ahs`. Puoi eliminare queste entità utilizzando modello Dataflow. Nota. Poiché App Engine archivia i dati di sessione Datastore e memcache, tutti i valori archiviati 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 tramite HTTP o HTTPS. Puoi configurare un'app in modo che richieda il protocollo HTTPS per determinati URL nella descrittore di deployment. Consulta Deployment Descrittore: URL protetti. Se vuoi impedire l'utilizzo di HTTPS per l'applicazione, inserisci il metodo nel file `appengine-web.xml`: <ssl-enabled>false</ssl-enabled> Non è possibile in alcun modo consentire l'utilizzo del protocollo HTTPS per alcuni percorsi URL e non per altri in Java. dell'ambiente di runtime.
`<static-error-handlers>`	Facoltativo. Quando si verificano determinati errori, App Engine restituisce un errore generico . 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 un elemento sezione `<static-error-handlers>` al tuo `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 dell'errore il file di risposta non si sovrappone ai percorsi dei gestori di file statici. Ogni voce `file` indica un file statico che dovrebbe essere fornita al posto della risposta di errore generico. La `error-code` indica il codice di errore che dovrebbe causare l'errore da pubblicare. 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 un elenco completo dei tipi MIME.
`<static-files>`	Facoltativo. L'elemento `<static-files>` specifica 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. Vengono pubblicati file statici da server e cache dedicati separati server delle applicazioni e sono utili per la distribuzione 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 valore predefinito il comportamento di inclusione di tutti i file non JSP. La L'elemento `<include>` può specificare HTTP intestazioni da utilizzare quando si risponde alla richiesta per il Google Cloud. Per ulteriori informazioni, vedi Inclusione ed esclusione 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. Per Ad esempio, `"4d 5h"` imposta la scadenza della cache a 4 giorni e 5 ore dopo che il file richiesta per la prima volta. Per ulteriori informazioni, consulta la sezione Cache scadenza. `<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 directory continueranno a essere accessibile alla tua applicazione quando viene eseguita di sviluppo. 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 il 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> 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 Server web Java per utilizzare i 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`, a indicare che il valore Le classi di rete Java utilizzano il trasporto HTTP(S) Java standard. Per utilizzare questa impostazione, devi attivare la fatturazione per la tua app oppure riceveranno eccezioni, documentate in Richieste di emissione. 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. Versione può contenere lettere minuscole, cifre e trattini. it non può iniziare con il prefisso "ah-" e i nomi "default" e "più recente" 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. Ciò evita l'ambiguità di URL come `123.my-module.uc.r.appspot.com`, che può essere interpretato in due modi: se la versione "123" esiste, 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 App Engine emette "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 disabilitare le richieste di warmup, specifica `false` per questa opzione : <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.

Elementi di scalabilità

La tabella seguente elenca le opzioni per definire come specificare l'applicazione deve scalare.

Per un confronto delle caratteristiche prestazionali 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 alla quale le nuove istanze iniziato a gestire il traffico, consentendoti di bilanciare le prestazioni e i costi, con valori più bassi che aumentano le prestazioni e un aumento dei costi e valori più alti che riducono il rendimento, e la riduzione dei costi. Ad esempio, il valore 0,7 significa che vengono avviate quando l'utilizzo della CPU raggiunge il 70%. `<target-throughput-utilization>` Facoltativa. Specifica un valore compreso tra 0,5 e 0,95. Utilizzato con `max-concurrent-requests` per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo. Quando di richieste in parallelo raggiunge un valore uguale a `max-concurrent-requests` volte `target-throughput-utilization`, lo scheduler avvia una nuova istanza. `<max-instances>` Facoltativa. Il numero massimo di istanze che App Engine può creare per questa versione dell'applicazione. Questo è utile per limitare i costi di un in maggior dettaglio più avanti in questo modulo. Specifica un valore compreso tra 0 e 2147483647. `<min-instances>` Facoltativa. Il numero minimo di istanze che App Engine deve creare per questa versione del modulo. Queste istanze gestiscono il traffico quando e continuano a gestire il traffico anche e vengono avviate altre istanze in base alle necessità per gestire il traffico. Specifica un valore compreso tra 0 e 1000. Puoi impostare il parametro sul valore 0 per consentire la scalabilità a 0 delle istanze Ridurre i costi se non vengono gestite richieste. Tieni presente che stai addebitato per il numero di istanze specificato che ricevono traffico o meno. `<max-concurrent-requests>` Facoltativo. Il numero di richieste in parallelo e una scalabilità automatica l'istanza può accettare prima che lo scheduler crei una nuova istanza (valore predefinito: 10, massimo: 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 del un'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 questi periodi carico di lavoro. Un valore massimo basso riduce i costi di gestione, ma può ridurne la qualità le prestazioni a fronte di livelli di carico volatile. Nota:per tornare ai livelli normali dopo un un picco di carico, il numero di istanze inattive può superare temporaneamente il valore massimo specificato. Tuttavia, non ti verrà addebitato alcun costo più istanze rispetto al numero massimo specificato. `<max-pending-latency>` Il periodo di tempo massimo che App Engine deve consentire di inviare una richiesta di attendere in coda prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre latenza in sospeso. 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 attendere più a lungo per le loro richieste la pubblicazione, se ci sono richieste in attesa e non c'è di Compute Engine, ma la tua applicazione costerà meno vengono eseguiti tutti i test delle unità. `<min-idle-instances>` Il numero di istanze da mantenere in esecuzione pronto a gestire il traffico.Questa impostazione si applica solo ai che riceve la maggior parte del traffico. Conserva quanto segue mente: Un minimo basso aiuta a mantenere bassi i costi di esercizio in caso di inattività ma significa che un numero minore di istanze potrebbe disponibili per rispondere a un improvviso picco di carico. Un minimo elevato ti consente di preparare l'applicazione dei picchi nel carico delle richieste. App Engine mantiene il numero minimo di in esecuzione per gestire le richieste in entrata. L'addebito viene eseguito per le istanze, che gestiscono o meno richieste. Affinché questa funzione funzioni correttamente, devi assicurarti che richieste di riscaldamento siano abilitate e che la tua applicazione 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>` La quantità di tempo minima in secondi che App Engine dovrebbe consentire una richiesta di attesa in coda prima di avviarne una nuova per gestirlo. Specifica un valore compreso tra 0,01 e 15. Un minimo basso significa che le richieste devono trascorrere meno tempo nell'attesa quando tutte le istanze esistenti sono attive. Ciò migliora 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>` Facoltativa. 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 può creare per questa versione del modulo. Questo è utile per limitare i costi di un in maggior dettaglio più avanti in questo 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 il ridimensionamento 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 alla quale le nuove istanze iniziato a gestire il traffico, consentendoti di bilanciare le prestazioni e i costi, con valori più bassi che aumentano le prestazioni e un aumento dei costi e valori più alti che riducono il rendimento, e la riduzione dei costi. Ad esempio, il valore 0,7 significa che vengono avviate quando l'utilizzo della CPU raggiunge il 70%.

<target-throughput-utilization>

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

Utilizzato con max-concurrent-requests per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo. Quando di richieste in parallelo raggiunge un valore uguale a max-concurrent-requests volte target-throughput-utilization, lo scheduler avvia una nuova istanza.

<max-instances>

Facoltativa. Il numero massimo di istanze che App Engine può creare per questa versione dell'applicazione. Questo è utile per limitare i costi di un in maggior dettaglio più avanti in questo modulo. Specifica un valore compreso tra 0 e 2147483647.

<min-instances>

Facoltativa. Il numero minimo di istanze che App Engine deve creare per questa versione del modulo. Queste istanze gestiscono il traffico quando e continuano a gestire il traffico anche e vengono avviate altre istanze in base alle necessità per gestire il traffico.

Specifica un valore compreso tra 0 e 1000. Puoi impostare il parametro sul valore 0 per consentire la scalabilità a 0 delle istanze Ridurre i costi se non vengono gestite richieste. Tieni presente che stai addebitato per il numero di istanze specificato che ricevono traffico o meno.

<max-concurrent-requests>

Facoltativo. Il numero di richieste in parallelo e una scalabilità automatica l'istanza può accettare prima che lo scheduler crei una nuova istanza (valore predefinito: 10, massimo: 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 del un'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 questi periodi carico di lavoro.
Un valore massimo basso riduce i costi di gestione, ma può ridurne la qualità le prestazioni a fronte di livelli di carico volatile.

Nota:per tornare ai livelli normali dopo un un picco di carico, il numero di istanze inattive può superare temporaneamente il valore massimo specificato. Tuttavia, non ti verrà addebitato alcun costo più istanze rispetto al numero massimo specificato.

<max-pending-latency>

Il periodo di tempo massimo che App Engine deve consentire di inviare una richiesta di attendere in coda prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre latenza in sospeso.

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 attendere più a lungo per le loro richieste la pubblicazione, se ci sono richieste in attesa e non c'è di Compute Engine, ma la tua applicazione costerà meno vengono eseguiti tutti i test delle unità.

<min-idle-instances>

Il numero di istanze da mantenere in esecuzione pronto a gestire il traffico.Questa impostazione si applica solo ai che riceve la maggior parte del traffico. Conserva quanto segue mente:

Un minimo basso aiuta a mantenere bassi i costi di esercizio in caso di inattività ma significa che un numero minore di istanze potrebbe disponibili per rispondere a un improvviso picco di carico.
Un minimo elevato ti consente di preparare l'applicazione dei picchi nel carico delle richieste. App Engine mantiene il numero minimo di in esecuzione per gestire le richieste in entrata. L'addebito viene eseguito per le istanze, che gestiscono o meno richieste. Affinché questa funzione funzioni correttamente, devi assicurarti che richieste di riscaldamento siano abilitate e che la tua applicazione 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>

La quantità di tempo minima in secondi che App Engine dovrebbe consentire una richiesta di attesa in coda prima di avviarne una nuova per gestirlo. Specifica un valore compreso tra 0,01 e 15.

Un minimo basso significa che le richieste devono trascorrere meno tempo nell'attesa quando tutte le istanze esistenti sono attive. Ciò migliora 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>: Facoltativa. 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 può creare per questa versione del modulo. Questo è utile per limitare i costi di un in maggior dettaglio più avanti in questo 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 il ridimensionamento 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 temporanei

Gran parte del lavoro svolto durante un deployment avviene localmente in una fase di preparazione chiamati staging, dove vengono assemblati i file JAR, compilati JSP 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 il deployment dell'app non viene eseguito, potrebbe essere necessario configurare la gestione temporanea 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 gestione temporanea ti consente di specificare una determinata fase se necessario per il deployment. Questo elemento può contenere i seguenti elementi: `<enable-jar-splitting>` Facoltativo. Suddividi i file jar di grandi dimensioni (> 10 MB) in file più piccoli. come il frammento frammentato. (valore predefinito: true). `<jar-splitting-excludes>` Specifica un elenco di suffissi dei file separati da virgole. Se `enable-jar-splitting` è abilitato, tutti i file che 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/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 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 gestione temporanea ti consente di specificare una determinata fase se necessario per il deployment.

Questo elemento può contenere i seguenti elementi:

<enable-jar-splitting>: Facoltativo. Suddividi i file jar di grandi dimensioni (> 10 MB) in file più piccoli. come il frammento frammentato. (valore predefinito: true).
<jar-splitting-excludes>: Specifica un elenco di suffissi dei file separati da virgole. Se enable-jar-splitting è abilitato, tutti i file che 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/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 sorgente per la compilazione. (valore predefinito: utf-8).

Ad esempio:

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

Impostazioni predefinite 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 della classe, quindi se la tua app dipende da un determinato ordine utilizzando la precedente impostazione predefinita di `false`, puoi impostarla 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ù di qualsiasi carattere nel nome di un file o di una directory e ** rappresenta zero o più in un percorso. File e directory corrispondenti a <exclude> i pattern non verranno caricati quando esegui il deployment dell'app in App Engine. Tuttavia, questi file e directory saranno ancora accessibili alla tua applicazione quando in esecuzione sul server di sviluppo locale.

Un elemento <include> sostituisce il comportamento predefinito di inclusione 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 quando rispondi alle richieste che Google Cloud.

<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 al 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>