Referencia de appengine-web.xml de App Engine

ID de región

El REGION_ID es un código abreviado que Google asigna en función de la región que selecciones al crear tu aplicación. El código no corresponde a un país o provincia, aunque algunos IDs de región pueden parecerse a los códigos de país y provincia que se usan habitualmente. En las aplicaciones creadas después de febrero del 2020, REGION_ID.r se incluye en las URLs de App Engine. En las aplicaciones creadas antes de esa fecha, el ID de región es opcional en la URL.

Más información sobre los IDs de región

Además del web.xmldescriptor de despliegue, las aplicaciones Java de App Engine usan un archivo de configuración llamado appengine-web.xml para especificar información sobre la aplicación e identificar qué archivos del archivo WAR de la aplicación son estáticos (como imágenes) y cuáles son archivos de recursos que usa la aplicación.

Ejemplo

En el siguiente ejemplo se muestra un archivo mínimo que especifica el tiempo de ejecución de Java 8 sin archivos estáticos ni de recursos:

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

Sintaxis

Una aplicación Java de App Engine debe tener un archivo llamado appengine-web.xml en su archivo WAR, en el directorio WEB-INF/. Se trata de un archivo XML cuyo elemento raíz es <appengine-web-app>.

Puedes encontrar la definición de tipo de documento y las especificaciones del esquema de appengine-web.xml en el directorio docs/ del SDK.

Elemento Descripción
<async-session-persistence>

Opcional. Puedes reducir la latencia de las solicitudes configurando tu aplicación para que escriba de forma asíncrona los datos de sesión HTTP en el almacén de datos: 

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

Si la persistencia de sesión asíncrona está activada, App Engine enviará una tarea de Task Queue para escribir los datos de sesión en el almacén de datos antes de escribir los datos en la memoria caché. De forma predeterminada, la tarea se enviará a la cola `default`. Si quieres usar otra cola, añade el atributo `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>

Los datos de sesión siempre se escriben de forma síncrona en memcache. Si una solicitud intenta leer los datos de la sesión cuando memcache no está disponible (o si los datos de la sesión se han purgado), se producirá un error y se recurrirá a Datastore, que puede que aún no tenga los datos de la sesión más recientes. Esto significa que la persistencia de sesiones asíncrona puede provocar que tu aplicación vea datos de sesión obsoletos. Sin embargo, en la mayoría de las aplicaciones, la latencia es mucho menor que el riesgo.

<auto-id-policy> Opcional. Si configura los identificadores de entidad automáticamente, puede cambiar el método que se utiliza configurando la política de ID automático. Estas son las opciones válidas:
default
Predeterminado. Usa IDs automáticos dispersos que son números enteros grandes y bien distribuidos, pero lo suficientemente pequeños como para representarse con números de coma flotante de 64 bits.
legacy
La opción antigua dejará de estar disponible en una versión futura y se eliminará. Para obtener más información, consulta la entrada de blog en la que se anuncia este cambio.
<automatic-scaling>

Opcional. Para obtener una explicación completa, consulta la sección Escalado automático.

<basic-scaling>

Opcional. Para obtener una explicación completa, consulta la sección sobre el escalado básico.

<env-variables>

Opcional. El archivo appengine-web.xml puede definir variables de entorno que se definen cuando se ejecuta la aplicación. 

<env-variables>
  <env-var name="DEFAULT_ENCODING" value="UTF-8" />
</env-variables>

Para evitar conflictos con tu entorno local, el servidor de desarrollo no define variables de entorno basadas en este archivo y requiere que el entorno local ya tenga estas variables definidas con valores coincidentes. 

export DEFAULT_ENCODING="UTF-8"
dev_appserver war

Cuando se despliega en App Engine, el entorno se crea con estas variables ya definidas.

<inbound-services>

Opcional. Para que una aplicación pueda recibir correos, debe configurarse para habilitar el servicio. Para habilitar el servicio en una aplicación Java 8, incluye una sección <inbound-services> en el archivo appengine-web.xml.

Está disponible el siguiente servicio entrante:

mail
Permite que tu aplicación reciba correo.
<instance-class>

Opcional. Tamaño de la clase de instancia de este módulo.

Las siguientes clases de instancia están disponibles al especificar diferentes opciones de escalado:

automatic_scaling
Cuando se usa el escalado automático, están disponibles las clases de instancia F1, F2, F4 y F4_1G.
Valor predeterminado: se asigna F1 si no especifica una clase de instancia junto con el elemento automatic_scaling.
basic_scaling
Cuando se usa el escalado básico, están disponibles las clases de instancia B1, B2, B4, B4_1G y B8.
Valor predeterminado: se asigna B2 si no especificas una clase de instancia junto con el elemento basic_scaling.
manual_scaling
Si usas el escalado manual, puedes usar las clases de instancia B1, B2, B4, B4_1G y B8.
Valor predeterminado: se asigna B2 si no especificas una clase de instancia junto con el elemento manual_scaling.

Nota: Si instance-class tiene el valor F2 o superior, puedes optimizar tus instancias configurando max-concurrent-requests con un valor superior a 10, que es el predeterminado. Para encontrar el valor óptimo, auméntalo gradualmente y monitoriza el rendimiento de tu aplicación.

<manual-scaling>

Opcional. Para obtener una explicación completa, consulta la sección Escalado manual.

<precompilation-enabled>

Opcional. App Engine usa un proceso de "precompilación" con el bytecode de Java de una aplicación para mejorar el rendimiento de la aplicación en el entorno de ejecución de Java. El código precompilado funciona de forma idéntica al bytecode original.

Si, por algún motivo, prefieres que tu aplicación no use la precompilación, puedes desactivarla añadiendo lo siguiente a tu archivo appengine-web.xml: 

<?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: Los módulos ahora se llaman Servicios y los servicios se siguen declarando en archivos appengine-web.xml como módulos. Por ejemplo: <module>service_name</module>.

Obligatorio si se crea un servicio. Opcional para el servicio predeterminado. Cada servicio y cada versión deben tener un nombre. Un nombre puede contener números, letras y guiones. No puede tener más de 63 caracteres, empezar o terminar con un guion ni contener la cadena `-dot`. Elige un nombre único para cada servicio y cada versión. No reutilices nombres entre servicios y versiones.

Consulta también servicio.

<public-root>

Opcional. <public-root> es un directorio de tu aplicación que contiene los archivos estáticos de la aplicación. Cuando se realiza una solicitud de un archivo estático, se añade el <public-root> de tu aplicación a la ruta de la solicitud. Esta opción proporciona la ruta de un archivo de aplicación que contiene el contenido solicitado.

El valor predeterminado <public-root> es /.

Por ejemplo, la siguiente asignación asignaría la ruta de la URL /index.html a la ruta del archivo de la aplicación /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>

Opcional. El código de la aplicación puede acceder a los archivos que se indican en el elemento <resource-files> mediante el sistema de archivos. Estos archivos se almacenan en los servidores de aplicaciones con la aplicación, a diferencia de cómo se almacenan y sirven los archivos estáticos.

El elemento <resource-files> puede contener los siguientes elementos:

<include>
Un elemento <include> designa los archivos como archivos de recursos y los pone a disposición del código de tu aplicación. Estos archivos solo están disponibles para tu código en modo de solo lectura y no para servir tráfico. Incluir y excluir archivos.
<exclude>

Los archivos y directorios que coincidan con los patrones de <exclude> no se subirán ni estarán disponibles para el código de tu aplicación. Sin embargo, tu aplicación podrá seguir accediendo a estos archivos y directorios cuando se ejecute en el servidor de desarrollo local. Para obtener más información, consulta el artículo sobre cómo incluir y excluir archivos.

Ejemplo: 
<resource-files>
  <include path="/**.xml" />
  <exclude path="/feeds/**.xml" />
</resource-files>

En este ejemplo se muestra cómo designar todos los archivos .xml como archivos de recursos, excepto los que se encuentran en el directorio feeds/ y en todos sus subdirectorios.

Los archivos de recursos de App Engine se leen con java.io.File o javax.servlet.ServletContext.getResource/getResourceAsStream. No se puede acceder a ellas a través de Class.getResourceAsStream().

runtime

Para usar el tiempo de ejecución de Java 8, debes especificar esta entrada con el valor java8.

Ejemplo: 

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

Antes, los servicios se conocían como módulos.

Actualmente, solo se pueden definir servicios como: <service>service_name</service > con los comandos de gcloud app.
service-account

Opcional. El elemento service-account te permite especificar una cuenta de servicio gestionada por el usuario como identidad de la versión. La cuenta de servicio especificada se usará al acceder a otros servicios y ejecutar tareas. Google Cloud

Ejemplo: 
<?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>

Opcional. App Engine incluye una implementación de sesiones que usa la interfaz de sesión de servlet. La implementación almacena los datos de sesión en Datastore para la persistencia y también usa memcache para mejorar la velocidad. Al igual que en la mayoría de los demás contenedores de servlets, los atributos de sesión que se definen con `session.setAttribute()` durante la solicitud se conservan al final de la solicitud.

Esta función está desactivada de forma predeterminada. Para activarlo, añade lo siguiente a appengine-web.xml:

Ejemplo: 
<?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>

La implementación crea entidades de Datastore del tipo _ah_SESSION y entradas de memcache con claves que tienen el prefijo _ahs. Puede eliminar estas entidades con la plantilla de Dataflow.

Nota: Como App Engine almacena los datos de sesión en Datastore y memcache, todos los valores almacenados en la sesión deben implementar la interfaz java.io.Serializable.

Consulta el elemento async-session-persistence para reducir la latencia del almacenamiento de datos de sesión.

<ssl-enabled>

Opcional. De forma predeterminada, los usuarios pueden acceder a cualquier URL mediante HTTP o HTTPS. Puede configurar una aplicación para que requiera HTTPS en determinadas URLs en el descriptor de implementación. Consulta Descriptor de implementación: URLs seguras.

Si quieres inhabilitar el uso de HTTPS en la aplicación, incluye lo siguiente en el archivo 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>

No hay forma de inhabilitar HTTPS para algunas rutas de URL y no para otras en el entorno de tiempo de ejecución de Java.

<static-error-handlers>

Opcional. Cuando se producen determinados errores, App Engine muestra una página de error genérica. Puedes configurar tu aplicación para que sirva un archivo estático personalizado en lugar de estas páginas de error genéricas, siempre que los datos de error personalizados no superen los 10 kilobytes. Puedes configurar diferentes archivos estáticos para que se publiquen para cada código de error admitido especificando los archivos en el archivo appengine-web.xml de tu aplicación. Para mostrar páginas de error personalizadas, añade una sección <static-error-handlers> a tu appengine-web.xml, como en este ejemplo: 

<static-error-handlers>
  <handler file="default_error.html" />
  <handler file="over_quota.html" error-code="over_quota" />
</static-error-handlers>

Advertencia: Asegúrate de que la ruta al archivo de respuesta de error no se superponga con las rutas del controlador de archivos estáticos.

Cada entrada file indica un archivo estático que debe servirse en lugar de la respuesta de error genérica. El error-code indica qué código de error debe provocar que se sirva el archivo asociado. Los códigos de error admitidos son los siguientes:

over_quota
Indica que la aplicación ha superado una cuota de recursos.
timeout
Se publica si se alcanza una fecha límite antes de que tu aplicación envíe una respuesta.

El error-code es opcional. Si no se especifica, el archivo indicado será la respuesta de error predeterminada de tu aplicación.

También puedes especificar un mime-type que se usará al mostrar el error personalizado. Consulta la lista completa de tipos MIME.

<static-files>

Opcional. El elemento <static-files> especifica patrones que coinciden con las rutas de los archivos que se van a incluir y excluir de la lista de archivos estáticos, lo que anula o modifica el comportamiento predeterminado. Los archivos estáticos se sirven desde servidores y cachés dedicados que están separados de los servidores de aplicaciones. Son útiles para servir contenido estático, como imágenes, hojas de estilo CSS o archivos JavaScript.

El elemento <static-files> puede contener los siguientes elementos:

<include>

Un elemento <include> anula el comportamiento predeterminado de incluir todos los archivos que no sean JSP. El elemento <include> puede especificar los encabezados HTTP que se deben usar al responder a las solicitudes de los recursos especificados. Para obtener más información, consulta el artículo sobre cómo incluir y excluir archivos.

Puede anular el vencimiento predeterminado de la caché estática especificando el atributo expiration en el elemento include. El valor es una cadena de números y unidades, separados por espacios, donde las unidades pueden ser d (días), h (horas), m (minutos) y s (segundos). Por ejemplo, "4d 5h" define la caducidad de la caché en 4 días y 5 horas después de que se solicite el archivo por primera vez. Para obtener más información, consulta Expiración de la caché.

<exclude>
Los archivos y directorios que coincidan con los patrones de <exclude> no se subirán cuando despliegues tu aplicación en App Engine. Sin embargo, tu aplicación podrá seguir accediendo a estos archivos y directorios cuando se ejecute en el servidor de desarrollo local. Para obtener más información, consulta el artículo sobre cómo incluir y excluir archivos.
Ejemplo 
<static-files>
  <include path="/my_static-files" >
    <http-header name="Access-Control-Allow-Origin"
                 value="http://example.org" />
  </include>
</static-files>
<system-properties>

Opcional. El archivo appengine-web.xml puede definir propiedades del sistema y variables de entorno que se definen cuando se ejecuta la aplicación. 

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

Obligatorio. Cuando el elemento threadsafe de appengine-web.xml es false, App Engine envía solicitudes de forma secuencial a un servidor web determinado. Si el valor es true, App Engine puede enviar varias solicitudes en paralelo: 

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

Si quieres usar solicitudes simultáneas, el código de tu aplicación debe usar la sincronización de subprocesos adecuada antes de habilitar threadsafe.

Este elemento no se admite en los entornos de ejecución de Java 11 y versiones posteriores.

<url-stream-handler>

Opcional. Los valores posibles son native o urlfetch.

El valor predeterminado es native, lo que significa que las clases de red Java estándar usan el transporte HTTP(S) de Java estándar. Para usar este ajuste, debes habilitar la facturación de tu aplicación. De lo contrario, recibirás excepciones, que se documentan en Solicitudes de problemas.

Si asignas el valor url-stream-handler a urlfetch, URL.openConnection y los métodos relacionados usarán la obtención de URLs para el transporte http y 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>

El elemento <version> contiene el identificador de versión de la última versión del código de la aplicación. El identificador de versión puede contener letras minúsculas, dígitos y guiones. No puede empezar por el prefijo "ah-". Los nombres "default" y "latest" están reservados y no se pueden usar.

Los nombres de las versiones deben empezar por una letra para distinguirlos de las instancias numéricas, que siempre se especifican con un número. De esta forma, se evita la ambigüedad con URLs como 123.my-module.uc.r.appspot.com, que se pueden interpretar de dos formas: si existe la versión "123", el destino será la versión "123" del módulo en cuestión. Si esa versión no existe, el destino será la instancia número 123 de la versión predeterminada del módulo.

App Engine usa este identificador de versión para determinar si debe crear una nueva versión de la aplicación con el identificador proporcionado (o sustituir la versión de la aplicación con el identificador proporcionado si ya existe). Puedes probar nuevas versiones de tu aplicación con una URL usando "-dot-" como separador de subdominios en la URL, como https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com. Con Google Cloud console, puedes seleccionar la versión predeterminada de tu aplicación. La versión predeterminada se carga cuando no se especifica ninguna versión o se especifica una versión no válida.

<warmup-requests-enabled>

Opcional. Valor predeterminado: true. Las solicitudes de preparación están habilitadas de forma predeterminada en las aplicaciones Java 8.

Si las solicitudes de calentamiento están habilitadas, la infraestructura de App Engine envía solicitudes `GET` a /_ah/warmup, inicializando servlets <load-on-startup>, ServletContextListeners y servlets de calentamiento personalizados, lo que te permite inicializar el código de tu aplicación según sea necesario. Es posible que tengas que implementar tu propio controlador para /_ah/warmup en función del método que elijas.

Para inhabilitar las solicitudes de preparación, especifica false en este elemento: 

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

Opcional. Configura tu aplicación para que use un conector de acceso a VPC sin servidor, lo que permite que la aplicación envíe solicitudes a recursos internos de tu red de VPC. Para obtener más información, consulta Conectarse a una red VPC.

name
Especifica el nombre completo de tu conector de acceso a VPC sin servidor: 
projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
egress-setting
Opcional. El valor predeterminado es private-ranges-only. El elemento egress-setting puede ser uno de los siguientes:
private-ranges-only
Predeterminado. Las solicitudes a direcciones IP internas se envían a través del conector de Acceso a VPC sin servidor a la red de VPC conectada. Las solicitudes a direcciones IP externas se envían a Internet público.
all-traffic
Todas las solicitudes se envían a través del conector de Acceso a VPC sin servidor a la red de VPC conectada.
Ejemplo 
<vpc-access-connector>
  <name>projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME</name>
  <egress-setting>all-traffic</egress-setting>
</vpc-access-connector>

Escalar elementos

En la siguiente tabla se enumeran las opciones para definir cómo debe escalarse tu aplicación.

Para ver una comparación de las funciones de rendimiento de los tipos de escalado, consulta Escalar instancias dinámicas.

Elemento Descripción
<automatic-scaling>

Opcional. El escalado automático se da por supuesto de forma predeterminada con una clase de instancia predeterminada de F1, a menos que se especifique lo contrario.

El elemento automatic_scaling define los niveles mínimo y máximo del número de instancias, la latencia y las conexiones simultáneas de un módulo.

Este elemento puede contener los siguientes elementos:

<target-cpu-utilization>
Opcional. Especifica un valor entre 0,5 y 0,95.

Este parámetro especifica el umbral de uso de la CPU en el que se iniciarán nuevas instancias para gestionar el tráfico, lo que te permite encontrar el equilibrio entre el rendimiento y el coste. Los valores más bajos aumentan el rendimiento y el coste, mientras que los valores más altos disminuyen el rendimiento y el coste. Por ejemplo, un valor de 0,7 significa que las nuevas instancias se iniciarán cuando el uso de la CPU alcance el 70 %.

<target-throughput-utilization>
Opcional. Especifica un valor entre 0,5 y 0,95.

Se usa con max-concurrent-requests para especificar cuándo se inicia una nueva instancia debido a solicitudes simultáneas. Cuando el número de solicitudes simultáneas alcanza un valor igual a max-concurrent-requests veces target-throughput-utilization, el programador inicia una nueva instancia.

<max-instances>
Opcional. El número máximo de instancias que puede crear App Engine para esta versión de la aplicación. Esto resulta útil para limitar los costes de un módulo. Especifica un valor entre 0 y 2147483647.
<min-instances>
Opcional. Número mínimo de instancias que debe crear App Engine para esta versión del módulo. Estas instancias sirven tráfico cuando llegan solicitudes y siguen sirviendo tráfico incluso cuando se inician instancias adicionales según sea necesario para gestionar el tráfico.

Especifica un valor entre 0 y 1000. Puede asignar el valor 0 al parámetro para permitir que se escale a 0 instancias y, de este modo, reducir los costes cuando no se sirvan solicitudes. Ten en cuenta que se te cobrará por el número de instancias especificadas, independientemente de si reciben tráfico o no.

<max-concurrent-requests>

Opcional. Número de solicitudes simultáneas que puede aceptar una instancia de escalado automático antes de que el programador genere una nueva instancia (valor predeterminado: 10; valor máximo: 80).

Si este ajuste es demasiado alto, puede que la latencia de la API aumente. Ten en cuenta que el programador puede generar una nueva instancia antes de que se alcance el número máximo real de solicitudes.

Nota: Si instance-class tiene el valor F2 o superior, puedes optimizar tus instancias configurando max-concurrent-requests con un valor superior a 10, que es el predeterminado. Para encontrar el valor óptimo, auméntalo gradualmente y monitoriza el rendimiento de tu aplicación.

<max-idle-instances>

El número máximo de instancias inactivas que App Engine debe mantener en esta versión. El valor predeterminado es "automático". Ten en cuenta lo siguiente:

  • Un valor máximo alto reduce el número de instancias inactivas de forma más gradual cuando los niveles de carga vuelven a la normalidad después de un pico. De esta forma, tu aplicación mantiene un rendimiento constante durante las fluctuaciones de la carga de solicitudes, pero también aumenta el número de instancias inactivas (y los costes de ejecución correspondientes) durante esos periodos de carga elevada.
  • Si el máximo es bajo, los costes de funcionamiento serán menores, pero el rendimiento puede verse afectado si los niveles de carga son volátiles.

Nota: Cuando se vuelve a los niveles normales después de un pico de carga, el número de instancias inactivas puede superar temporalmente el máximo especificado. Sin embargo, no se te cobrarán más instancias que el número máximo que hayas especificado.

<max-pending-latency>

Tiempo máximo que debe permitir App Engine que espere una solicitud en la cola pendiente antes de iniciar instancias adicionales para gestionar las solicitudes, de forma que se reduzca la latencia pendiente.

  • Un valor máximo bajo significa que App Engine iniciará nuevas instancias antes para las solicitudes pendientes, lo que mejorará el rendimiento, pero aumentará los costes de ejecución.
  • Si el valor máximo es alto, es posible que los usuarios tengan que esperar más para que se atiendan sus solicitudes si hay solicitudes pendientes y no hay instancias inactivas para atenderlas, pero el coste de ejecutar tu aplicación será menor.
<min-idle-instances>

El número de instancias que deben mantenerse en ejecución y listas para servir tráfico.Este ajuste solo se aplica a la versión que recibe la mayor parte del tráfico. Ten en cuenta lo siguiente:

  • Un mínimo bajo ayuda a mantener bajos los costes de funcionamiento durante los periodos de inactividad, pero significa que es posible que haya menos instancias disponibles de inmediato para responder a un pico de carga repentino.

  • Un mínimo alto te permite preparar la aplicación para picos rápidos en la carga de solicitudes. App Engine mantiene el número mínimo de instancias en ejecución para atender las solicitudes entrantes. Se te cobrará por las instancias, independientemente de si gestionan solicitudes o no. Para que esta función funcione correctamente, debes asegurarte de que las solicitudes de calentamiento estén habilitadas y de que tu aplicación gestione las solicitudes de calentamiento.

    Si defines un número mínimo de instancias inactivas, la latencia pendiente afectará menos al rendimiento de tu aplicación. Como App Engine mantiene instancias inactivas en reserva, es poco probable que las solicitudes entren en la cola pendiente, excepto en picos de carga excepcionalmente altos. Deberá probar su aplicación y el volumen de tráfico previsto para determinar el número ideal de instancias que debe mantener en reserva.

<min-pending-latency>

Tiempo mínimo en segundos que App Engine debe permitir que una solicitud espere en la cola pendiente antes de iniciar una nueva instancia para gestionarla. Especifica un valor entre 0,01 y 15.

  • Un mínimo bajo significa que las solicitudes deben pasar menos tiempo en la cola pendiente cuando todas las instancias existentes estén activas. De esta forma, se mejora el rendimiento, pero aumenta el coste de ejecutar la aplicación.
  • Un mínimo alto significa que las solicitudes permanecerán pendientes más tiempo si todas las instancias existentes están activas. De esta forma, se reducen los costes de ejecución, pero aumenta el tiempo que deben esperar los usuarios para que se atiendan sus solicitudes.
Ejemplo 
<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>

Opcional. El elemento <basic-scaling> define el número de instancias de un módulo.

Este elemento puede contener los siguientes elementos:

<idle-timeout>
Opcional. La instancia se cerrará al cabo de este tiempo después de recibir su última solicitud. El valor predeterminado es de 5 minutos.
<max-instances>
Obligatorio. El número máximo de instancias que puede crear App Engine para esta versión del módulo. Esto resulta útil para limitar los costes de un módulo.
Ejemplo 
<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>

Opcional. El elemento <manual-scaling> permite escalar manualmente un módulo y define el número de instancias de un módulo.

Este elemento puede contener los siguientes elementos:

<instances>
Número de instancias que se asignarán al módulo al inicio.
Ejemplo 
<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>

Elementos de puesta en escena

Gran parte del trabajo que se realiza durante una implementación se lleva a cabo de forma local en un paso de preparación llamado puesta en escena, donde se ensamblan los archivos JAR, se compilan los JSPs, etc. También puedes configurar ciertas partes del comportamiento de la fase de pruebas mediante elementos de la fase de pruebas en el archivo de configuración de la aplicación. La mayoría de las aplicaciones se desplegarán correctamente sin tener que configurar manualmente el comportamiento de la fase de pruebas. Si tu aplicación no se implementa, puede que tengas que configurar la fase de pruebas con las opciones que se muestran a continuación.

Elemento Descripción
<staging>

Opcional. La mayoría de las aplicaciones no necesitan cambiar el comportamiento predeterminado.

El elemento de staging te permite especificar una configuración de staging concreta si es necesario para la implementación.

Este elemento puede contener los siguientes elementos:

<enable-jar-splitting>

Opcional. Divide los archivos JAR grandes (más de 10 megabytes) en fragmentos más pequeños. El valor predeterminado es "true".

<jar-splitting-excludes>

Especifica una lista de sufijos de archivo separados por comas. Si enable-jar-splitting está habilitado, todos los archivos que coincidan con los sufijos se excluirán de todos los archivos JAR.

<disable_jar_jsps>

No empaquetes en JAR las clases generadas a partir de JSPs. Valor predeterminado: false.

<enable-jar-classes>

Empaqueta el contenido de WEB-INF/classes. Valor predeterminado: false.

<delete-jsps>

Elimina los archivos de origen JSP después de la compilación. El valor predeterminado es "true".

<compile-encoding>

Codificación de entrada de los archivos de origen para la compilación. El valor predeterminado es utf-8.

Por ejemplo:

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

Valores predeterminados de la opción de staging

Los valores predeterminados de las opciones de puesta en escena son los siguientes:

Elemento de staging Valor predeterminado
enable-jar-splitting true
jar-splitting-excludes N/A
disable-jar-jsps false
enable-jar-classes true. Esto puede afectar al orden de carga de las clases, por lo que, si tu aplicación depende de un orden concreto, asigna el valor false.
delete-jsps true
compile-encoding utf-8

Sintaxis de inclusión y exclusión

Los patrones de ruta se especifican mediante cero o más elementos <include> y <exclude>. En un patrón, '*' representa cero o más caracteres de cualquier tipo en un nombre de archivo o directorio, y ** representa cero o más directorios en una ruta. Los archivos y directorios que coincidan con los patrones de <exclude> no se subirán cuando despliegues tu aplicación en App Engine. Sin embargo, tu aplicación podrá seguir accediendo a estos archivos y directorios cuando se ejecute en el servidor de desarrollo local.

Un elemento <include> anula el comportamiento predeterminado de incluir todos los archivos. Un elemento <exclude> se aplica después de todos los patrones <include> (así como el predeterminado si no se proporciona ningún <include> explícito).

En el siguiente ejemplo se muestra cómo designar todos los archivos .png como archivos estáticos (excepto los que se encuentran en el directorio data/ y en todos sus subdirectorios):

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

También puedes definir los encabezados HTTP que se usarán al responder a las solicitudes de estos recursos estáticos.

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

Tipos MIME de archivos estáticos

De forma predeterminada, los archivos estáticos se sirven con un tipo MIME seleccionado en función de la extensión del nombre de archivo. Puedes asociar tipos de MIME personalizados con extensiones de nombre de archivo para archivos estáticos mediante elementos <mime-mapping> en web.xml.

Tiempo de espera de URLFetch

Puedes definir una fecha límite para cada solicitud URLFetch. De forma predeterminada, el límite de tiempo de una extracción es de cinco segundos. Para cambiar este valor predeterminado, incluye el siguiente ajuste en tu archivo de configuración appengine-web.xml. Especifica el tiempo de espera en segundos:

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