Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
ID de región
REGION_ID es un código abreviado que Google asigna en función de la región que eliges cuando creas la app. El código no corresponde a un país ni a una provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia que se suelen usar. En el caso de las apps creadas después de febrero de 2020, REGION_ID.r se incluye en las URL de App Engine. En el caso de las apps existentes creadas antes de esta fecha, el ID de región es opcional en la URL.
Debes establecer la configuración de tu app de App Engine en el archivo de configuración app.yaml. Tu archivo de configuración debe especificar al menos una entrada runtime.
Cada servicio de tu app tiene su propio archivo app.yaml, que actúa como descriptor para su implementación. Debes crear el archivo app.yaml para el servicio default antes de que puedas crear y, luego, implementar archivos app.yaml en servicios adicionales en la app. Para obtener más información sobre cómo estructurar servicios múltiples en tu aplicación, consulta Cómo estructurar servicios web en App Engine.
El formato YAML admite el uso de comentarios. Se ignoran las líneas que comienzan con el signo numeral (#):
# This is a comment.
Los patrones de ruta de archivo y URL usan la sintaxis de expresiones regulares extendidas de POSIX y excluyen los elementos y las clases de intercalación. Se admiten referencias inversas a las coincidencias agrupadas (p. ej.: \1), al igual que estas extensiones de Perl: \w \W \s \S \d \D.
Ejemplo
El siguiente es un ejemplo de un archivo app.yaml:
runtime:python312instance_class:F2env_variables:BUCKET_NAME:"example-gcs-bucket"handlers:# Matches requests to /images/... to files in static/images/...-url:/imagesstatic_dir:static/images-url:/.*secure:alwaysredirect_http_response_code:301script:auto
Opcional. Establece un período de caché predeterminado global para todos los controladores de archivos estáticos de una aplicación. También puedes configurar la duración de la caché para controladores de archivos estáticos específicos. El valor es una string de números y unidades, separados por espacios, en la que las unidades pueden ser d para días, h para horas, m para minutos y s para segundos. Por ejemplo, con "4d 5h" se establece el vencimiento de la caché dentro de 4 días y 5 horas después de que se solicita el archivo por primera vez. Si se omite, el servidor de producción establece el vencimiento dentro de 10 minutos.
Opcional.
Anula el comportamiento de inicio predeterminado mediante la ejecución del comando entrypoint cuando se inicia la app. Para que la app reciba solicitudes HTTP, el elemento entrypoint debe contener un comando que inicie un servidor web que reciba datos en el puerto 8080.
Si no especificas entrypoint para el entorno de ejecución de Python, App Engine configura y, luego, inicia el servidor web de Gunicorn.
Opcional.
Puedes definir variables de entorno en el archivo app.yaml a fin de que estén disponibles para la app. Asegúrate de que la clave en las variables de entorno coincida con la expresión “[a-zA-Z_][a-zA-Z0-9_]*” (comienza con una letra o “_” seguida de cualquier carácter alfanumérico o “_”).
Las variables de entorno que tienen el prefijo GAE se reservan para el uso del sistema y no están permitidas en el archivo app.yaml.
Para Python, estas variables están disponibles en el diccionario os.environ:
Se entrega si se alcanza un plazo antes de que exista una respuesta por parte de la app.
El error_code es opcional; si no se especifica, el archivo es la respuesta de error predeterminada para la app.
file
Cada entrada de archivo indica un archivo estático que debe entregarse en lugar de la respuesta de error genérica. Si especificas un elemento file sin el elemento error_code correspondiente, la página de error predeterminada de la app será el archivo estático. Los datos de error personalizados deben pesar menos de 10 kilobytes.
Opcional.
Una lista de patrones de URL y descripciones acerca de cómo deben manejarse.
App Engine puede manejar las URL mediante la ejecución del código de aplicación, o la entrega de archivos estáticos subidos con el código, como imágenes, CSS o JavaScript.
Opcional.
Las aplicaciones deben habilitar esos servicios para poder recibir solicitudes entrantes. Para habilitar el servicio para una app, incluye una sección inbound_services en el archivo app.yaml.
Los siguientes valores están disponibles según el escalamiento del servicio:
Ajuste de escala automático
F1, F2, F4, F4_1G
Predeterminada:F1
De manera opcional, usa el elemento automatic_scaling para cambiar la configuración predeterminada del ajuste de escala automático, como la cantidad mínima y máxima de instancias, la latencia y las conexiones simultáneas.
Nota: Si instance_class está configurado como F2 o superior, puedes optimizar tus instancias si estableces max_concurrent_requests en un valor superior al valor predeterminado de 10. Para determinar el valor óptimo, auméntalo de manera gradual y supervisa el rendimiento de la aplicación.
Escalamiento básico y manual
B1, B2, B4, B4_1G, B8
Predeterminada:B2
Las clases de instancias básicas y manuales requieren que especifiques el elemento basic_scaling o el elemento manual_scaling.
runtime
Obligatorio. El nombre del entorno de ejecución que usa la app. Por ejemplo, para especificar el entorno de ejecución, usa lo siguiente:
runtime:python312
service
Es obligatorio si se crea un servicio.
Es opcional para el servicio default. Cada servicio y versión deben tener un nombre. Un nombre puede contener números, letras y guiones. En el entorno flexible, la longitud combinada de VERSION-dot-SERVICE-dot-PROJECT_ID (en la que VERSION es el nombre de tu versión, SERVICE es el nombre de tu servicio y PROJECT_ID es el ID del proyecto) no puede tener más de 63 caracteres y no puede empezar o terminar con un guion. Elige un nombre único para cada servicio y cada versión. No vuelvas a usar nombres entre servicios y versiones.
Ejemplo:
service:service-name
service_account
Opcional. El elemento service_account te permite especificar una cuenta de servicio específica de la versión como la identidad para la versión. La cuenta de servicio especificada se usará para acceder a otros servicios de Google Cloud y ejecutar tareas.
Opcional.
Configura la aplicación para que use un conector de Acceso a VPC sin servidores, lo que le permite enviar solicitudes a recursos internos de tu red de VPC. Para obtener más información, consulta Conéctate a una red de VPC.
name
Literal de string. Especifica el nombre completamente calificado de tu conector de Acceso a VPC sin servidores entre comillas:
Opcional. La ruta predeterminada es private-ranges-only. El egress_setting puede ser una de las siguientes opciones:
private-ranges-only
Predeterminado. Las solicitudes a las direcciones IP internas se envían a través del conector de Acceso a VPC sin servidores a la red de VPC conectada. Las solicitudes a direcciones IP externas se envían a la Internet pública.
all-traffic
Todas las solicitudes se envían a través del conector de Acceso a VPC sin servidores a la red de VPC conectada.
El elemento handlers proporciona una lista de patrones de URL y descripciones acerca de cómo controlarlos. App Engine puede controlar las URL mediante la ejecución del código de aplicación o la entrega de los archivos estáticos subidos con el código, como imágenes, CSS o JavaScript.
Los patrones se evalúan en el orden en que aparecen en el archivo app.yaml, de arriba abajo. Para controlar la solicitud, se utiliza la primera asignación cuyo patrón coincide con la URL.
En la siguiente tabla, se muestran los subelementos del elemento handlers que controlan el comportamiento de los archivos estáticos, los directorios estáticos, las secuencias de comandos en entornos de ejecución distintos de Node.js y otras opciones de configuración.
Elemento
Descripción
auth_fail_action
Para usar este elemento, app_engine_apis debe configurarse como true.
Opcional.
Describe la acción realizada cuando se especifica el elemento login para un controlador y el usuario no accedió. Tiene dos valores posibles:
redirect
Predeterminado. Se redirige al usuario a la página de inicio de sesión de Google o /_ah/login_required si se usa la autenticación OpenID.
Se redirecciona de nuevo al usuario a la URL de la aplicación después de acceder a la cuenta o crear una.
unauthorized
Se rechaza la solicitud con un código de estado HTTP 401 y un mensaje de error.
Si una aplicación necesita un comportamiento diferente, esta puede implementar el control de los accesos de los usuarios. Por ejemplo, se requiere un acceso para el directorio /profile/ o un acceso de administrador para el directorio /admin/. Consulta la API de usuarios para obtener más información.
Puedes configurar un controlador para que rechace el acceso a las URL protegidas cuando el usuario no accedió, en lugar de redireccionar al usuario a la página de acceso. Para ello, agrega auth_fail_action: unauthorized a la configuración del controlador:
expiration
Opcional.
El tiempo durante el cual los proxies y los navegadores web deben almacenar en caché el archivo estático que entrega este controlador. El valor es una string de números y unidades, separados por espacios, en la que las unidades pueden ser d por días, h por horas, m por minutos y s por segundos. Por ejemplo, "4d 5h" establece el vencimiento de la caché en 4 días y 5 horas después de que se solicita el archivo por primera vez. Si se omite, se usa el default_expiration de la aplicación. Consulta Vencimiento de la caché para obtener más detalles.
http_headers
Opcional. Puedes configurar los encabezados HTTP para las respuestas del archivo estático o los controladores de directorio.
Si necesitas establecer encabezados HTTP en los controladores de script, debes hacerlo en el código de la app. Para obtener información sobre qué encabezados de respuesta influyen en el almacenamiento en caché, consulta Almacena en caché el contenido estático.
Un uso importante de esta función es admitir el uso compartido de recursos multiorigen (CORS), como el acceso a archivos alojados por otra app de App Engine.
Por ejemplo, puedes tener una app de juegos mygame.uc.r.appspot.com que acceda a los recursos alojados en myassets.uc.r.appspot.com.
Sin embargo, si mygame intenta hacer un JavaScript XMLHttpRequest a myassets, no tendrá éxito, a menos que el controlador de myassets muestre un encabezado de respuesta Access-Control-Allow-Origin: que contenga el valor http://mygame.uc.r.appspot.com.
A continuación, se muestra cómo tendrías que hacer para que el controlador de archivos estáticos muestre ese valor de encabezado de respuesta requerido:
Sugerencia: Para permitir que todos accedan a sus recursos, puedes usar el comodín '*', en lugar de https://mygame.uc.r.appspot.com.
login
Para usar este elemento, app_engine_apis debe configurarse como true.
Opcional.
Determina si el controlador de URL requiere que el usuario haya ingresado.
Este elemento tiene tres valores posibles:
optional
Predeterminado. No requiere que el usuario haya accedido.
required
Si el usuario accedió, el controlador procede con normalidad. De lo contrario, se toma la medida indicada en auth_fail_action.
admin
Al igual que con required, se realiza auth_fail_action si el usuario no accedió. Además, si el usuario no es un administrador de la aplicación, recibirá un mensaje de error, más allá de la configuración auth_fail_action. Si el usuario es un administrador, el controlador continúa.
Cuando un controlador de URL con una configuración login distinta de optional coincide con una URL, el controlador primero comprueba si el usuario accedió a la aplicación con la opción de autenticación. De lo contrario, por configuración predeterminada, se redirecciona al usuario a la página de acceso. También puedes usar auth_fail_action para configurar la app a fin de que simplemente rechace las solicitudes de un controlador de usuarios que no estén autenticados de forma correcta, en lugar de redirigir al usuario a la página de inicio de sesión.
Nota: La restricción de inicio de sesión admin también se cumple con las solicitudes internas para las cuales App Engine establece los encabezados especiales X-Appengine apropiados. Por ejemplo, las tareas programadas cron satisfacen la restricción admin, porque App Engine establece un encabezado HTTP X-Appengine-Cron: true en las solicitudes respectivas.
Sin embargo, las solicitudes no satisfarían la restricción de inicio de sesión required porque las tareas programadas cron no se ejecutan como ningún usuario.
mime_type
Opcional. Si se especifica, todos los archivos que entrega el controlador se entregarán mediante el uso del tipo MIME especificado. Si no se especifica, el tipo MIME para un archivo se derivará de la extensión del nombre del archivo.
Si el mismo archivo se sube con varias extensiones, la extensión resultante puede depender del orden en que se subieron.
Opcional. Se usa redirect_http_response_code con la configuración secure para establecer el código de respuesta HTTP que se muestra cuando se realiza una redirección obligatoria por la configuración de secure.
El elemento redirect_http_response_code puede tener los siguientes valores:
301
Código de respuesta Movido permanentemente.
302
Código de respuesta Encontrado.
303
Código de respuesta Ver otros.
307
Código de respuesta Redireccionamiento temporal.
Cuando se redirecciona una solicitud de un usuario, el código de estado HTTP se establecerá en el valor del parámetro redirect_http_response_code. Si el parámetro no está presente, se mostrará 302.
script
Opcional.
Especifica que las solicitudes al controlador específico deben orientarse a tu app. El único valor aceptado para el elemento script es auto porque todo el tráfico se entrega con el comando entrypoint. A fin de usar controladores estáticos, al menos uno de tus controladores debe contener la línea script: auto o definir un elemento entrypoint para que se implemente de forma correcta.
secure
Opcional. Cualquier controlador de URL puede usar la configuración secure, incluidos los controladores de archivos estáticos. El elemento secure puede tener los siguientes valores:
optional
Las solicitudes HTTP y HTTPS con URL que coinciden con el controlador se realizan de forma correcta sin redireccionamientos. La aplicación puede examinar la solicitud para determinar qué protocolo se utilizó, y responder según corresponda. Este es el valor predeterminado cuando no se proporciona secure para un controlador.
never
Las solicitudes para una URL que coinciden con este controlador y que usan HTTPS se redireccionan de manera automática a la URL HTTP equivalente. Cuando la solicitud HTTPS del usuario se redirecciona para que sea una solicitud HTTP, los parámetros de consulta se quitan de la solicitud. Así se evita que el usuario envíe por accidente datos de consulta a través de una conexión no segura que se diseñó para una conexión segura.
always
Las solicitudes para una URL que coinciden con este controlador y que no usan HTTPS se redireccionan de forma automática a la URL HTTPS con la misma ruta. Los parámetros de consulta se conservan para el redireccionamiento.
Para orientar una versión específica de la app mediante el dominio REGION_ID.r.appspot.com, reemplaza los puntos que separan los componentes del subdominio de la URL por la string “-dot-”, como se muestra en el ejemplo siguiente: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
El ingreso a las Cuentas de Google y el cierre de sesión siempre se realizan mediante el uso de una conexión segura, no relacionada con la forma en que se configuran las URL de la aplicación.
static_dir
Opcional. La ruta al directorio que contiene los archivos estáticos, desde el directorio raíz de la aplicación. Todo después del final del patrón url coincidente se agrega a static_dir para formar la ruta completa del archivo solicitado.
Cada archivo en el directorio estático se entrega mediante un tipo MIME que coincide con la extensión del nombre del archivo, a menos que el ajuste mime_type del directorio lo anule. Todos los archivos en el directorio se suben como archivos estáticos y ninguno de ellos puede ejecutarse como secuencias de comandos.
Ejemplo:
handlers:# All URLs beginning with /stylesheets are treated as paths to# static files in the stylesheets/ directory.-url:/stylesheetsstatic_dir:stylesheets# ...
static_files
Opcional. Un controlador de patrón de archivo estático asocia un patrón de URL con las rutas a los archivos estáticos subidos con la aplicación. La expresión regular del patrón de URL puede definir agrupaciones de expresiones regulares que se utilizarán en la construcción de la ruta del archivo. Puedes usar esto en lugar de static_dir para asignar a archivos específicos en una estructura de directorio sin asignar el directorio completo.
Ejemplo:
handlers:# All URLs ending in .gif .png or .jpg are treated as paths to# static files in the static/ directory. The URL pattern is a# regular expression, with a grouping that is inserted into the# path to the file.-url:/(.*\.(gif|png|jpg))$static_files:static/\1upload:static/.*\.(gif|png|jpg)$# ...
Los archivos estáticos no pueden ser los mismos que los archivos de código de la aplicación.
upload
Opcional. Una expresión regular que coincide con las rutas de los archivos para todos los archivos a los que el controlador hará referencia. Esto es necesario porque el controlador no puede determinar qué archivos en el directorio de la aplicación coinciden con los patrones url y static_files específicos. Los archivos estáticos se suben y manejan por separado de los archivos de la aplicación. En el ejemplo anterior, se puede usar el siguiente patrón upload: archives/(.*)/items/(.*)
url
Elemento obligatorio en handlers. El patrón de URL, como expresión regular que puede contener agrupaciones. Por ejemplo, /profile/(.*)/(.*) coincidiría con la URL /profile/edit/manager y usaría edit y manager como la primera y segunda agrupación.
El patrón de URL tiene algunas diferencias en el comportamiento cuando se usa con los siguientes elementos:
Usa un prefijo de URL. El patrón de expresión regular no debe contener agrupaciones cuando se usa con el elemento static_dir. Este controlador maneja todas las URL que comienzan con este prefijo mediante el uso de la parte de la URL después del prefijo como parte de la ruta del archivo.
Un controlador de patrón de archivo estático asocia un patrón de URL con las rutas a los archivos estáticos subidos con la aplicación. La expresión regular del patrón de URL puede definir agrupaciones de expresiones regulares que se utilizarán en la creación de la ruta del archivo. Puedes usar esto en lugar de static_dir para mapear a archivos específicos en una estructura de directorio sin mapear el directorio completo.
Elementos de escalamiento
Los elementos de la siguiente tabla configuran el escalamiento de tu aplicación. Si no se especifica un tipo de escalamiento, se establece el ajuste de escala automático de forma predeterminada.
A fin de obtener más información para escalar las apps de App Engine, consulta Tipos de escalamiento.
Elemento
Descripción
automatic_scaling
Opcional. Solo se aplica a las aplicaciones que usan una clase de instancia de F1 o superior.
Especifica este elemento a fin de cambiar la configuración predeterminada del ajuste de escala automático, como establecer niveles mínimos y máximos para la cantidad de instancias, la latencia y las conexiones simultáneas de un servicio.
Puede contener los siguientes elementos:
max_instances
Opcional. Especifica un valor de entre 0 y 2147483647, en el que cero inhabilita la configuración.
Este parámetro especifica el número máximo de instancias que App Engine debe crear para esta versión del módulo. Esto es útil para limitar los costos de un módulo.
min_instances
Opcional. El número mínimo de instancias que App Engine debe crear para esta versión del módulo. Estas instancias entregan tráfico cuando llegan solicitudes y continúan haciéndolo incluso cuando se inician instancias adicionales según sea necesario para manejar el tráfico.
Especifica un valor de 0 a 1,000. Puedes configurar el parámetro en el valor 0 para permitir que el escalamiento a 0 instancias reduzca los costos cuando no se entregan solicitudes. Ten en cuenta que se te cobrará por el número de instancias especificadas, ya sea que reciban tráfico o no.
max_idle_instances
Opcional. El número máximo de instancias inactivas que App Engine debería mantener para esta versión. Especifica un valor de 1 a 1,000. Si no se especifica, el valor predeterminado es automatic, lo que significa que App Engine administrará la cantidad de instancias inactivas.
Ten en cuenta lo siguiente:
Un máximo alto reduce el número de instancias inactivas de manera más gradual cuando los niveles de cargo vuelven a la normalidad después de un pico. Esto ayuda a que la aplicación mantenga un rendimiento constante a través de las fluctuaciones en la carga de solicitud, pero también aumenta el número de instancias inactivas (y los consiguientes costos de ejecución) durante los períodos de carga pesada.
Un máximo bajo mantiene los costos de ejecución más bajos, pero puede degradar el rendimiento ante niveles de carga volátiles.
Nota: Cuando se vuelve a los valores normales después de un pico de carga, el número de instancias inactivas puede superar de forma temporal el máximo especificado. Sin embargo, no se te cobrarán más instancias que el número máximo que hayas especificado.
min_idle_instances
Opcional: Es el número de instancias adicionales que se seguirán ejecutando y están listas a fin de entregar tráfico para esta versión.
App Engine calcula la cantidad de instancias necesarias para entregar el tráfico de la aplicación actual según la configuración de escalamiento, como target_cpu_utilization y target_throughput_utilization. La configuración de min_idle_instances especifica la cantidad de instancias que se ejecutarán además de esta cantidad calculada. Por ejemplo, si App Engine calcula que se necesitan 5 instancias para entregar tráfico y min_idle_instances se configura en 2, App Engine ejecutará 7 instancias (5, que se calculan en función de tráfico, más 2 adicionales por min_idle_instances).
Ten en cuenta que se te cobrará por el número de instancias especificadas, ya sea que reciban tráfico o no. Ten en cuenta lo siguiente:
Un mínimo bajo ayuda a mantener bajos los costos de ejecución durante los períodos de inactividad, pero significa que hay menos instancias inmediatamente disponibles 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 solicitud. App Engine mantiene el número mínimo de instancias en ejecución para entregar las solicitudes entrantes. Se te cobrará por el número de instancias especificadas, ya sea que manejen solicitudes o no.
Si estableces un mínimo de instancias inactivas, la latencia pendiente tendrá menos efecto en el rendimiento de tu aplicación.
target_cpu_utilization
Opcional. Especifica un valor entre 0.5 y 0.95. El valor predeterminado es 0.6.
Este parámetro especifica el límite de uso de la CPU en el que se iniciarán instancias nuevas para manejar el tráfico, lo que te permite balancear el rendimiento y el costo. Los valores más bajos aumentan el rendimiento y el costo, y los valores más altos disminuyen el rendimiento, pero también el costo. Por ejemplo, un valor de 0.7 implica que se iniciarán instancias nuevas luego de que el uso de CPU alcance el 70%.
target_throughput_utilization
Opcional. Especifica un valor de 0.5 a 0.95. El valor predeterminado es 0.6.
Se usa con max_concurrent_requests para especificar cuándo se inicia una instancia nueva debido a solicitudes simultáneas. Cuando la cantidad de solicitudes simultáneas alcanza un valor igual a max_concurrent_requests por target_throughput_utilization, el programador intenta iniciar una instancia nueva.
max_concurrent_requests
Opcional. La cantidad de solicitudes simultáneas que una instancia con ajuste de escala automático puede aceptar antes de que el programador genere una instancia nueva (el valor predeterminado es 10 y el máximo es 1000).
Se usa con target_throughput_utilization para especificar cuándo se inicia una instancia nueva debido a solicitudes simultáneas.
Cuando la cantidad de solicitudes simultáneas alcanza un valor igual a max_concurrent_requests por target_throughput_utilization, el programador intenta iniciar una instancia nueva.
Te recomendamos que no configures max_concurrent_requests con un valor menor que 10, a menos que necesites un subproceso único. Es probable que un valor inferior a 10 genere más instancias de las que necesitas en una app segura para los subprocesos, lo que puede generar costos innecesarios.
Si esta configuración es demasiado alta, es posible que experimentes una mayor latencia de la API. Ten en cuenta que el programador puede generar una instancia nueva antes de que se alcance la cantidad máxima real de solicitudes.
max_pending_latency
La cantidad máxima de tiempo que App Engine debe permitir que una solicitud espere en la lista de pendientes antes de iniciar instancias adicionales para controlar las solicitudes a fin de reducir la latencia pendiente. Cuando se alcanza este límite, es señal de que se debe aumentar la escala, y se traduce en un aumento en la cantidad de instancias.
Si no se especifica, el valor predeterminado es automatic. Esto significa que las solicitudes pueden permanecer en la lista de pendientes durante un máximo de 10 s, el límite de tiempo de solicitud pendiente máximo, antes de que se active una instancia nueva.
Un máximo bajo significa que App Engine iniciará instancias nuevas antes para las solicitudes pendientes, lo que mejora el rendimiento, pero aumenta los costos de ejecución.
Un máximo alto significa que los usuarios podrían esperar más tiempo hasta que se entreguen las solicitudes (si existen solicitudes pendientes y no hay instancias inactivas para entregarlas), pero la ejecución de tu aplicación costará menos.
min_pending_latency
Un elemento opcional que puedes establecer para especificar el tiempo mínimo que App Engine debe permitir que una solicitud espere en la cola de pendientes antes de iniciar una instancia nueva a fin de controlarla.
Especificar un valor puede reducir los costos de ejecución, pero aumenta el tiempo que los usuarios deben esperar para que se entreguen sus solicitudes.
En el caso de las apps gratuitas, el valor predeterminado es 500ms. Para las apps pagadas, el valor predeterminado es 0.
Este elemento funciona junto con el elemento max_pending_latency para determinar cuándo App Engine crea instancias nuevas.
Si hay solicitudes pendientes en la cola, ocurre lo siguiente:
Si hay menos de la min_pending_latency que especifiques, App Engine no creará instancias nuevas.
Si hay más de la max_pending_latency, App Engine intentará crear una instancia nueva.
Si el tiempo es uno entre el especificado por min_pending_latency y max_pending_latency, App Engine intentará volver a usar una instancia existente. Si ninguna instancia puede procesar la solicitud antes de la max_pending_latency, App Engine creará una instancia nueva.
Este elemento habilita el ajuste de escala básico de las clases de instancia B1 y superiores, y puede contener los siguientes elementos:
max_instances
Obligatorio. El número máximo de instancias que App Engine debe crear para esta versión de servicio. Esto es útil para limitar los costos de un servicio.
idle_timeout
Opcional. La instancia se desactivará durante este período después de recibir la última solicitud. El valor predeterminado es de 5 minutos (5m)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2024-11-20 (UTC)"],[],[]]
