Riferimento appengine-web.xml App Engine

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

Oltre al descrittore di deployment web.xml, le applicazioni Java di App Engine utilizzano un file di configurazione denominato appengine-web.xml per specificare informazioni sulla tua app e identificare quali file nel file WAR dell'app sono file statici (come le immagini) e quali sono i file di risorse utilizzati dall'applicazione.

Esempio

L'esempio seguente è un file minimo che specifica il comando Java 8 senza file statici o di risorse:

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <threadsafe>true</threadsafe>
  <runtime>java8</runtime>
</appengine-web-app>

Sintassi

Un'app Java App Engine deve avere un file denominato appengine-web.xml nel suo file 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
<async-session-persistence>

Facoltativo. È possibile ridurre la latenza delle richieste configurando per scrivere in modo asincrono i dati di sessione HTTP datastore: 

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <async-session-persistence enabled="true" />
  <!-- ... -->
</appengine-web-app>

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 vuoi utilizzare una coda diversa, aggiungi l'attributo "queue-name": 

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <async-session-persistence enabled="true" queue-name="myqueue"/>
  <!-- ... -->
</appengine-web-app>

I dati della 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 in Datastore, che potrebbero non disporre ancora dei dati 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
In una release futura, l'opzione precedente verrà ritirata e alla fine verrà rimossa. 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 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 sono già impostate.

<inbound-services>

Facoltativo. Prima che un'applicazione possa ricevere email, l'applicazione deve essere configurata per abilitare il servizio. Puoi abilitare il servizio per un'app Java 8 includendo 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. La dimensione della classe di istanze 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.
Predefinito: B2 viene assegnato se non specifichi un instance insieme alla classe 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 della tua 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 al bytecode originale.

Se per qualche motivo preferisci che la tua app non utilizzi la precompilazione, puoi disattivarla aggiungendo quanto segue al appengine-web.xml file: 

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <precompilation-enabled>false</precompilation-enabled>
  <!-- ... -->
</appengine-web-app>
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. Viene visualizzato il percorso di un file dell'applicazione contenente i contenuti richiesti.

Il valore predefinito di <public-root> è /.

Ad esempio, il seguente mappa il percorso dell'URL /index.html al percorso del file dell'applicazione /static/index.html: 

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <public-root>/static</public-root>
  <!-- ... -->
</appengine-web-app>
<resource-files>

Facoltativo. I file elencati nell'elemento <resource-files> sono accessibili al codice dell'applicazione tramite il file system. Questi file vengono archiviati sui server delle applicazioni con l'app, a differenza di come vengono archiviati e pubblicati i file statici.

L'elemento <resource-files> può contenere i seguenti elementi:

<include>
Un elemento <include> designa i file come di risorse e disponibili per il codice della tua applicazione. Questi file sono disponibili per il codice solo in sola lettura e non per gestione del 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, consulta Includi ed escludi 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 il runtime Java 8, devi specificare questa voce con il valore java8.

Esempio: 

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <runtime>java8</runtime>
  <!-- ... -->
</appengine-web-app>
service

I servizi erano precedentemente noti come moduli.

Al momento, la definizione di un servizio come: <service>service_name</service > è supportata solo dai comandi gcloud app.
service-account

Facoltativo. L'elemento service-account ti 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: 
<?xml version="1.0" encoding="utf-8"?>
 <appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
   <!-- ... -->
   <service-account>[SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com</service-account>
   <!-- ... -->
 </appengine-web-app>
<sessions-enabled>

Facoltativo. App Engine include un'implementazione delle sessioni utilizzando l'interfaccia di sessione del 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: 
<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <sessions-enabled>true</sessions-enabled>
  <!-- ... -->
</appengine-web-app>

L'implementazione crea entità Datastore di tipo _ah_SESSION e voci memcache utilizzando chiavi con un prefisso _ahs. Puoi eliminare queste entità utilizzando il 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.

Consulta l'elemento async-session-persistence per ridurre la latenza dell'archiviazione dei dati della 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 HTTPS per determinati URL nel descrittore di deployment. Consulta Deployment Descrittore: URL protetti.

Se vuoi non consentire l'utilizzo di HTTPS per l'applicazione, inserisci quanto segue nel file appengine-web.xml: 

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <ssl-enabled>false</ssl-enabled>
  <!-- ... -->
</appengine-web-app>

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 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 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 dell'errore il file di risposta non si sovrappone ai percorsi dei gestori di file statici.

Ogni voce file indica un file statico da caricare al posto della risposta generica all'errore. 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 una quota di risorse.
timeout
Viene pubblicato se viene raggiunta una scadenza prima che la tua app risponda.

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 per la generazione dell'errore personalizzato. Consulta un 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. La L'elemento <include> può specificare HTTP intestazioni da utilizzare quando si risponde alla richiesta per Google Cloud. Per ulteriori informazioni, consulta Includi ed escludi i 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 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>
<threadsafe>

Obbligatorio. Quando l'elemento threadsafe in appengine-web.xml è false, app Il motore invia le richieste in modo seriale a un determinato server web. Quando il valore è true, App Engine può inviare più richieste in parallelo: 

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <threadsafe>true</threadsafe>
  <!-- ... -->
</appengine-web-app>

Se vuoi utilizzare richieste in parallelo, il codice dell'applicazione deve utilizzare una sincronizzazione dei thread corretta prima di abilitare threadsafe.

Questo elemento non è supportato nei runtime Java 11 e versioni successive.

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

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <url-stream-handler>urlfetch</url-stream-handler>
  <!-- ... -->
</appengine-web-app>
<version>

L'elemento <version> contiene l'identificatore della versione dell'ultima versione del codice dell'app. 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 istanze 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.

App Engine utilizza questo identificatore di versione per determinare se per creare una nuova versione dell'app con l'identificatore specificato (o sostituire la versione dell'app con l'identificatore specificato, se disponibile esiste già). Puoi testare nuove versioni della tua app con un URL utilizzando "-punto-" come separatore di sottodominio nell'URL, ad esempio https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com. Nella console Google Cloud puoi selezionare la versione predefinita dell'app. La versione predefinita viene caricata quando non vengono o una versione non valida.

<warmup-requests-enabled>

Facoltativo. Valore predefinito: true. Le richieste di warmup sono abilitate per impostazione predefinita per le applicazioni Java 8.

Con le richieste di riscaldamento abilitate, l'infrastruttura di App Engine invia richieste "GET" a /_ah/warmup, inizializzando servlet <load-on-startup>, ServletContextListeners e servlet di riscaldamento personalizzati, che ti consentono di inizializzare il codice dell'applicazione in base alle esigenze. Potresti dover implementare il tuo gestore per /_ah/warmup a seconda di quale di questi metodi scegli.

Per disabilitare le richieste di warmup, specifica false per questa opzione : 

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <!-- ... -->
  <warmup-requests-enabled>false</warmup-requests-enabled>
  <!-- ... -->
</appengine-web-app>
<vpc-access-connector>

Facoltativo. Configura l'applicazione in modo che utilizzi un connettore di accesso VPC serverless, in modo che possa inviare richieste alle risorse interne della rete VPC. Per ulteriori informazioni, consulta Connessione a una rete VPC.

name
Specifica il nome completo del connettore di accesso VPC serverless: 
projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
egress-setting
Facoltativo. Il valore predefinito è private-ranges-only. egress-setting può essere uno dei seguenti:
private-ranges-only
Valore predefinito. Le richieste agli indirizzi IP interni vengono inviate tramite il connettore di accesso VPC serverless alla rete VPC collegata. Richieste a IP esterno indirizzi IP vengono inviati alla rete internet pubblica.
all-traffic
Tutte le richieste vengono inviate tramite Connettore di accesso VPC serverless alla rete VPC connessa.
Esempio 
<vpc-access-connector>
  <name>projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME</name>
  <egress-setting>all-traffic</egress-setting>
</vpc-access-connector>

Ridimensionare gli elementi

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

Per un confronto delle caratteristiche prestazionali dei tipi di scalabilità, consulta Scalabilità delle istanze dinamiche.

Elemento Descrizione
<automatic-scaling>

Facoltativo. Per impostazione predefinita, viene applicata la scalabilità automatica con una classe di istanza predefinita di F1, a meno che non venga specificato diversamente.

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>
Facoltativo. 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, 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 concorrenti. Quando il numero di richieste simultanee 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. 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 che App Engine deve creare 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 la scalabilità a 0 delle istanze Ridurre i costi se non vengono gestite 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 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 il programmatore 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 il rendimento del un'applicazione.

<max-idle-instances>

Il numero massimo di istanze inattive che App Engine dovrebbe per questa versione. Il valore predefinito è "automatic". 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. 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 verranno addebitati costi aggiuntivi 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 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 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 in esecuzione il numero minimo di istanze per gestire le richieste in entrata. L'addebito viene eseguito per le istanze, che gestiscono o meno richieste. Affinché questa funzionalità funzioni correttamente, devi assicurarti che le richieste di riscaldamento siano attivate e che la tua applicazione le gestisca.

    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 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 valore minimo elevato significa che le richieste rimarranno in attesa più a lungo se tutte le istanze esistenti sono attive. In questo modo si riducono i costi di gestione, ma aumenta il tempo di attesa degli utenti per l'elaborazione delle loro richieste.
Esempio 
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <threadsafe>true</threadsafe>
  <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>
Facoltativa. L'istanza verrà arrestata dopo questo periodo di tempo dalla ricezione dell'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. 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>
  <threadsafe>true</threadsafe>
  <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>
  <threadsafe>true</threadsafe>
  <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 una fase di preparazione chiamati staging, dove vengono assemblati i file JAR, compilati JSP e così via. Se vuoi, puoi configurare alcune parti del comportamento di staging utilizzando gli elementi di staging nel file di configurazione dell'applicazione. La maggior parte delle applicazioni verrà implementata correttamente senza dover configurare manualmente il comportamento di staging. Se l'app non viene dispiata, potrebbe essere necessario configurare lo staging utilizzando le opzioni mostrate di seguito.

Elemento Descrizione
<staging>

Facoltativo. Per la maggior parte delle applicazioni non è necessario 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 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: false).

<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 i seguenti:

Elemento temporaneo Valore predefinito
enable-jar-splitting true
jar-splitting-excludes NA
disable-jar-jsps false
enable-jar-classes true. Questo può influire sull'ordine di caricamento delle classi, quindi se la tua app dipende da un determinato ordine, imposta questo valore su false.
delete-jsps true
compile-encoding 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. 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 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 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 questo valore predefinito includendo la seguente impostazione nel appengine-web.xml file di configurazione. Specifica il timeout in secondi:

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