PHP 5 ha llegado al final del ciclo de asistencia y quedará obsoleto el 31 de enero del 2026. Después de la retirada, no podrás desplegar aplicaciones PHP 5, aunque tu organización haya usado anteriormente una política de organización para volver a habilitar los despliegues de los tiempos de ejecución antiguos. Tus aplicaciones PHP 5 seguirán funcionando y recibiendo tráfico después de la
fecha de retirada. Te recomendamos que migres a la versión compatible más reciente de PHP.
Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
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.
Configura los ajustes de tu aplicación de App Engine en el archivo app.yaml.
Este archivo especifica cómo se corresponden las rutas de las URLs con los controladores de solicitudes y los archivos estáticos.
El archivo app.yaml también contiene información sobre el código de la aplicación, como el tiempo de ejecución y el identificador de la versión más reciente.
Cada servicio de tu aplicación tiene su propio archivo app.yaml, que actúa como descriptor de su implementación. Primero debes crear el archivo app.yaml para el servicio default antes de poder crear e implementar archivos app.yaml para otros servicios de tu aplicación.
A continuación, se muestra un ejemplo de un archivo app.yaml para una aplicación PHP 5:
runtime:php55api_version:1handlers:# Serve images as static resources.-url:/(.+\.(gif|png|jpg))$static_files:\1upload:.+\.(gif|png|jpg)$application_readable:true# Serve php scripts.-url:/(.+\.php)$script:\1
En el ejemplo anterior, los archivos con las extensiones gif, png o jpg se servirán como recursos estáticos. Los archivos se han configurado para que el código de la aplicación pueda leerlos en el tiempo de ejecución.
El ejemplo también servirá todos los scripts PHP. Puedes restringir el controlador de secuencias de comandos a las secuencias de comandos de nivel raíz mediante la expresión url: /([^/]+\.php). Puede que las aplicaciones ya existentes necesiten simular el enrutamiento de Apache mod_rewrite$_GET['q'].
A continuación, se muestra una app.yaml más extensa:
El formato YAML admite comentarios. Se ignora una línea que empieza por el carácter almohadilla (#):
# This is a comment.
Los patrones de URL y de ruta de archivo usan la sintaxis de expresiones regulares extendidas POSIX, excepto los elementos de ordenación y las clases de ordenación. Se admiten las referencias inversas a coincidencias agrupadas (por ejemplo, \1)
y estas extensiones de Perl: \w \W \s \S \d \D.
Tiempo de ejecución y elementos de la aplicación
Elemento
Descripción
application
Lo más recomendable es quitar el elemento application
del archivo app.yaml y, en su lugar, usar una marca de línea de comandos para especificar el ID de la aplicación:
Para usar el comando
gcloud app deploy, debes especificar la marca --project:
Cuando Google anuncie la compatibilidad con una nueva versión de la API de un entorno de ejecución, tu aplicación desplegada seguirá usando la versión para la que se escribió. Para actualizar tu aplicación a una nueva versión de la API, cambia este valor y vuelve a implementar la aplicación en App Engine. Si especifica el valor 1
, se usará el entorno de ejecución compatible más reciente cada vez que
despliegue esa aplicación (actualmente, ).
Por el momento, App Engine tiene una versión del phpentorno de ejecución1:
default_expiration
Opcional. Define un periodo de caché predeterminado global para todos los controladores de archivos estáticos de una aplicación. También puedes configurar una duración de la caché para controladores de archivos estáticos específicos. El valor es una cadena de números y unidades, separados por espacios, donde las unidades pueden ser d para días, h para horas, m para minutos y s para segundos. Por ejemplo, "4d 5h" establece la caducidad de la caché
en 4 días y 5 horas después de que se solicite el archivo por primera vez. Si se omite, el servidor de producción establece la caducidad en 10 minutos.
Opcional.
Puedes definir variables de entorno en el archivo app.yaml
para que estén disponibles en tu aplicación. Asegúrate de que la clave de las variables de entorno coincida con la expresión "[a-zA-Z_][a-zA-Z0-9_]*" (empieza por una letra o "_" seguida de cualquier carácter alfanumérico o "_").
Las variables de entorno que tienen el prefijo
GAE están reservadas para el uso del sistema y no se permiten en el archivo
app.yaml.
Ejemplo:
env_variables:MY_VAR:"myvalue"
donde MY_VAR y my value son el nombre y el valor de la variable de entorno que quieres definir. Cada entrada de variable de entorno tiene una sangría de dos espacios en el elemento env_variables. Las variables de entorno a las que no se les ha asignado ningún valor tienen el valor predeterminado "None".
Después, puede obtener el valor de estas variables mediante getenv() o $_SERVER, pero no$_ENV. Los siguientes comandos muestran el valor de la variable de entorno MY_VAR:
echo getenv('MY_VAR');
o
echo $_SERVER['MY_VAR'];
error_handlers
Opcional.
Se usa para configurar páginas de error personalizadas que se devuelven para diferentes tipos de error.
Este elemento puede contener los siguientes elementos:
error_code
Opcional. El elemento error_code puede ser uno de los siguientes:
Se publica si se alcanza una fecha límite antes de que tu aplicación
envíe una respuesta.
El código de error es opcional. Si no se especifica, el archivo proporcionado es la respuesta de error predeterminada de tu aplicación.
file
Cada entrada de archivo indica un archivo estático que se debe servir en
lugar de la respuesta de error genérica. Si especifica un elemento file sin el elemento error_code correspondiente, el archivo estático será la página de error predeterminada de su aplicación.
Los datos de error personalizados deben tener un tamaño inferior a 10 kilobytes.
Obligatorio.
Una lista de patrones de URL y descripciones sobre cómo se deben procesar.
App Engine puede gestionar URLs ejecutando código de aplicación o sirviendo 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. Puedes habilitar el servicio en una aplicación PHP 5
incluyendo una sección inbound_services en el archivo
app.yaml.
Están disponibles los siguientes valores en función del escalado de tu servicio:
Escalado automático
F1, F2, F4, F4_1G
Predeterminado:F1
También puedes usar el elemento automatic_scaling para cambiar los ajustes predeterminados del escalado automático, como el número mínimo y máximo de instancias, la latencia y las conexiones simultáneas.
Nota: Si instance_class
tiene el valor F2 o superior, puede optimizar sus instancias
definiendo max_concurrent_requests con un valor superior al
valor predeterminado de 10. Para determinar el valor óptimo, auméntalo gradualmente y monitoriza el rendimiento de tu aplicación.
Escalado básico y manual
B1, B2, B4, B4_1G, B8
Predeterminado:B2
Las clases de instancia básicas y manuales requieren que especifiques el elemento basic_scaling o el elemento manual_scaling.
module
Nota: Los módulos ahora se llaman "Servicios".
Para gestionar tu aplicación con gcloud CLI, usa el elemento service.
runtime
Obligatorio. El nombre del entorno de ejecución que usa tu aplicación. Por ejemplo, para especificar PHP 5, usa lo siguiente:
runtime:php55
service
Antes, los servicios se llamaban módulos.
Solo se admite en la CLI de gcloud o en los complementos basados en la CLI de gcloud. Por ejemplo, gcloud app deploy.
Obligatorio si se crea un
servicio.
Opcional para el servicio default. Cada servicio y cada versión deben tener un nombre. El nombre puede contener números, letras y guiones. La longitud combinada de VERSION-dot-SERVICE-dot-PROJECT_ID, donde VERSION es el nombre de tu versión, SERVICE es el nombre de tu servicio y PROJECT_ID es el ID de tu proyecto, no puede superar los 63 caracteres ni empezar o terminar con un guion. Elige un nombre único para cada servicio
y cada versión. No reutilices nombres entre servicios y versiones.
Ejemplo:
service:service-name
Nota: El comando gcloud app
deploy es compatible con versiones anteriores y admite archivos app.yaml que incluyan servicios declarados como módulos. Por ejemplo:
module:service-name
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 usa al acceder a otros Google Cloud servicios y ejecutar tareas.
Opcional.
El elemento skip_files especifica qué archivos del directorio de la aplicación no se deben subir a App Engine.
El valor es una expresión regular o una lista de expresiones regulares. Cualquier nombre de archivo que coincida con alguna de las expresiones regulares se omitirá de la lista de archivos que se van a subir cuando se suba la aplicación. Los nombres de archivo dependen del directorio del proyecto.
skip_files tiene el siguiente valor predeterminado:
El patrón predeterminado excluye los archivos de copia de seguridad de Emacs con nombres del tipo #...# y ...~, .pyc y .pyo, los archivos de un directorio de control de versiones RCS y los archivos ocultos de Unix con nombres que empiezan por un punto (.).
Para ampliar la lista de expresiones regulares anterior, copia y pega la lista anterior en tu app.yaml y añade tus propias expresiones regulares. Por ejemplo, para omitir los archivos cuyos nombres terminen en
.bak además de los patrones predeterminados, añade una entrada
como esta para skip_files:
Para omitir un directorio completo, añade el nombre del directorio a la lista. Por ejemplo, para omitir un directorio llamado logs,
añade la siguiente línea a las que se han descrito anteriormente:
skip_files:-logs/
version
Lo más recomendable es eliminar el elemento version
de tu archivo app.yaml y, en su lugar, usar una marca de línea de comandos para especificar tu ID de versión:
Para obtener más información sobre cómo usar este comando, consulta el artículo
Implementar tu aplicación.
Identificador de la versión del código de la aplicación que despliega en App Engine.
El ID 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.
Nota: 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-dot-my-service.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 servicio en cuestión. Si esa versión no existe, el destino será la instancia número 123 de la versión predeterminada del servicio.
Cada versión de una aplicación conserva su propia copia de app.yaml. Cuando se sube una aplicación, la versión
mencionada en el archivo app.yaml que se está subiendo es la
versión que se crea o se sustituye con la subida. Un administrador puede cambiar la versión de la aplicación que está sirviendo tráfico mediante el comando Google Cloud consoley también puede probar otras versiones antes de configurarlas para que reciban tráfico.
Elemento Handlers
El elemento handlers es obligatorio en el archivo de configuración app.yaml. El elemento proporciona una lista de patrones de URL y descripciones de cómo deben gestionarse. App Engine puede gestionar URLs ejecutando código de aplicación o sirviendo 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. Se usa la primera asignación cuyo patrón coincida con la URL para gestionar la solicitud.
En la siguiente tabla se enumeran los subelementos del elemento handlers que controlan el comportamiento de las secuencias de comandos, los archivos estáticos, los directorios estáticos y otros ajustes.
Elemento
Descripción
application_readable
Opcional. Booleano. De forma predeterminada, los archivos declarados en los controladores de archivos estáticos se suben como datos estáticos y solo se sirven a los usuarios finales. Las aplicaciones no pueden leerlas. Si este campo tiene el valor true, los archivos también se suben como datos de código para que tu aplicación pueda leerlos.
Ambas subidas se contabilizan en las cuotas de recursos de almacenamiento de datos estáticos y de código.
Opcional.
El tiempo que un archivo estático servido por este controlador debe almacenarse en caché por proxies web y navegadores. El valor es una cadena de números y unidades separados por espacios. 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. Si se omite, se usará el de la aplicación.
default_expiration. Consulta más información sobre la caducidad de la caché.
http_headers
Opcional. Puedes definir encabezados HTTP para las respuestas de tus controladores de archivos estáticos o de directorios. Si necesitas definir encabezados HTTP en tus controladores script, debes hacerlo en el código de tu aplicación. Para obtener información sobre qué encabezados de respuesta influyen en el almacenamiento en caché, consulta Almacenamiento en caché de contenido estático.
Uno de los usos importantes de esta función es admitir el uso compartido de recursos entre dominios (CORS), como acceder a archivos alojados en otra aplicación de App Engine.
Por ejemplo, puedes tener una aplicación de juego mygame.uc.r.appspot.com
que acceda a recursos alojados en myassets.uc.r.appspot.com.
Sin embargo, si mygame intenta hacer una llamada de JavaScript
XMLHttpRequest a myassets, no se completará
a menos que el controlador de myassets devuelva un encabezado de respuesta Access-Control-Allow-Origin: que contenga el valor http://mygame.uc.r.appspot.com.
A continuación, se explica cómo hacer que el controlador de archivos estáticos devuelva ese valor de encabezado de respuesta obligatorio:
Nota: Si quieres permitir que todos los usuarios accedan a tus recursos, puedes usar el comodín '*' en lugar de https://mygame.uc.r.appspot.com.
mime_type
Opcional. Si se especifica, todos los archivos que sirva este controlador se servirán con el tipo MIME especificado. Si no se especifica, el tipo MIME de un archivo se derivará de la extensión del nombre de archivo.
Si se sube el mismo archivo con varias extensiones, la extensión resultante puede depender del orden en el que se hayan subido los archivos.
Opcional. redirect_http_response_code se usa con el ajuste secure para definir el código de respuesta HTTP que se devuelve al realizar una redirección necesaria según la configuración del ajuste secure.
El elemento redirect_http_response_code puede tener los siguientes valores:
Cuando se redirige la solicitud de un usuario, el código de estado HTTP se asignará al valor del parámetro redirect_http_response_code. Si el parámetro no está presente, se devolverá 302.
script
Opcional.
Especifica la ruta a la secuencia de comandos desde el directorio raíz de la aplicación:
...handlers:-url:/profile/(.*)/(.*)script:/employee/\2/\1.php# specify a script
Opcional. Cualquier controlador de URLs puede usar el ajuste secure, incluidos los controladores de secuencias de comandos y los controladores de archivos estáticos. El elemento secure puede tener los siguientes valores:
optional
Las solicitudes HTTP y HTTPS con URLs que coincidan con el controlador
se completarán sin redirecciones. La aplicación puede examinar la solicitud para determinar qué protocolo se ha usado y responder en consecuencia. Este es el valor predeterminado cuando no se proporciona secure para un controlador.
never
Las solicitudes de una URL que coincida con este controlador y que use HTTPS se redirigen automáticamente a la URL HTTP equivalente. Cuando la solicitud HTTPS de un usuario se redirige para que sea una solicitud HTTP, los parámetros de consulta se eliminan de la solicitud. De esta forma, se evita que un usuario envíe por error datos de consulta a través de una conexión no segura que estaba destinada a una conexión segura.
always
Las solicitudes de una URL que coincida con este controlador y que no use HTTPS se
redirigen automáticamente a la URL HTTPS con la misma ruta. Los parámetros de consulta se conservan en la redirección.
El servidor web de desarrollo no admite las conexiones HTTPS. Ignora el parámetro secure, por lo que las rutas diseñadas para usarse con HTTPS se pueden probar mediante conexiones HTTP normales al servidor web de desarrollo.
El inicio y el cierre de sesión de las cuentas de Google siempre se realizan mediante una conexión segura, independientemente de cómo se configuren las URLs de la aplicación.
static_dir
Opcional. Ruta al directorio que contiene los archivos estáticos, desde el directorio raíz de la aplicación. Todo lo que haya después del final del patrón url coincidente se añade a static_dir para formar la ruta completa al archivo solicitado.
Cada archivo del directorio estático se sirve con el tipo MIME que
corresponde a la extensión de su nombre de archivo, a menos que se anule con el ajuste mime_type del directorio. Todos los archivos del directorio indicado se suben como archivos estáticos y ninguno de ellos se puede ejecutar como secuencia de comandos.
Todos los archivos de este directorio se suben con tu aplicación como archivos estáticos. App Engine almacena y sirve archivos estáticos por separado de los archivos de tu aplicación. Los archivos estáticos no están disponibles en el sistema de archivos de la aplicación de forma predeterminada. Para cambiarlo, define la opción application_readable como true.
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 patrones de archivos estáticos asocia un patrón de URL con rutas a 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 utilicen en la creación de la ruta del archivo. Puedes usarlo en lugar de
static_dir para asignar archivos específicos de una estructura de directorios
sin asignar todo el directorio.
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)$# ...
App Engine almacena y sirve archivos estáticos por separado de los archivos de la aplicación. Los archivos estáticos no están disponibles en el sistema de archivos de la aplicación de forma predeterminada. Para cambiarlo, define la opción application_readable como true.
Los archivos estáticos no pueden ser los mismos que los archivos de código de la aplicación.
Si una ruta de archivo estática coincide con la ruta de una secuencia de comandos utilizada en un controlador dinámico, la secuencia de comandos no estará disponible para el controlador dinámico.
upload
Opcional. Una expresión regular que coincida con las rutas de archivo de todos los archivos a los que hará referencia este controlador. Esto es necesario porque el controlador no puede determinar qué archivos del directorio de tu aplicación corresponden a los patrones url y static_files. Los archivos estáticos se suben y se gestionan por separado de los archivos de la aplicación. En el ejemplo
anterior, se podría usar el siguiente patrón upload:
archives/(.*)/items/(.*)
url
Elemento obligatorio en handlers. El patrón de URL, como una expresión regular. La expresión puede contener agrupaciones a las que se puede hacer referencia en la ruta de archivo de la secuencia de comandos con referencias inversas de expresiones regulares. Por ejemplo, /profile/(.*)/(.*) coincidiría con la URL /profile/edit/manager y usaría edit y manager como primer y segundo grupo, respectivamente.
El patrón de URL tiene algunas diferencias de 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 utilice con el elemento static_dir. Todas las URLs que empiecen por este prefijo se gestionarán con este controlador, usando la parte de la URL que va después del prefijo como parte de la ruta del archivo.
Un controlador de patrones de archivos estáticos asocia un patrón de URL con rutas a
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 usarán en la creación de la ruta del archivo. Puedes usarlo en lugar de
static_dir para asignar archivos específicos de una estructura de directorios
sin asignar todo el directorio.
Escalar elementos
Los elementos de la siguiente tabla configuran cómo se escala tu aplicación. Para obtener más información sobre cómo se escalan las aplicaciones de App Engine, consulta Tipos de escalado.
Elemento
Descripción
automatic_scaling
Opcional. Solo se aplica a las aplicaciones que usan una clase instance de F1 o superior.
Especifica este elemento para cambiar la configuración predeterminada del escalado automático, como los niveles mínimo y máximo del número de instancias, la latencia y las conexiones simultáneas de un servicio.
Este elemento puede contener los siguientes elementos:
max_instances
Opcional. Especifica un valor entre 0 y 2147483647. Si es cero, se inhabilita el ajuste.
Este parámetro especifica el número máximo de instancias que App Engine puede crear para esta versión del módulo. Esto resulta útil para limitar los costes 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 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_idle_instances
Opcional. El número máximo de instancias inactivas que
App Engine debe mantener para esta versión. Especifica un valor entre 1 y 1000. Si no se especifica ningún valor, se utiliza automatic de forma predeterminada, lo que significa que App Engine gestionará el número de instancias inactivas.
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.
min_idle_instances
Opcional: Número de instancias adicionales que se mantendrán en ejecución
y listas para servir tráfico para esta versión.
App Engine calcula el número de instancias necesarias para gestionar el tráfico actual de tu aplicación en función de los ajustes de escalado, como target_cpu_utilization y target_throughput_utilization. El ajuste min_idle_instances
especifica el número de instancias que se van a
ejecutar además del número calculado. Por ejemplo, si App Engine calcula que se necesitan 5 instancias para atender el tráfico y min_idle_instances se define como 2, App Engine ejecutará 7 instancias (5, calculadas en función del tráfico, más 2 adicionales por min_idle_instances).
Ten en cuenta que se te cobrará por el número de instancias especificadas, independientemente de si reciben tráfico o no. 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 en ejecución el número mínimo de instancias para atender las solicitudes entrantes. Se te cobra por el número de instancias especificadas, independientemente de si gestionan solicitudes o no.
Si defines un número mínimo de instancias inactivas, la latencia pendiente afectará menos al 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 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. El valor predeterminado es 0.6.
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 intenta iniciar una instancia nueva.
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. El valor predeterminado es 5 y el máximo es 1000.
Se usa con target_throughput_utilization 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 intenta
iniciar una instancia nueva.
Te recomendamos que no definas max_concurrent_requests
en un valor inferior a 10 a menos que necesites un solo subproceso. Si el valor es inferior a 10, es probable que se creen más instancias de las que necesitas para una aplicación segura para subprocesos, lo que puede generar costes innecesarios.
Si este ajuste es demasiado alto, es posible 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.
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. Cuando se alcanza este umbral, se envía una señal para aumentar la escala, lo que provoca un incremento en el número de instancias.
Si no se especifica ningún valor, se utiliza automatic de forma predeterminada. Esto significa que las solicitudes pueden permanecer en la cola pendiente hasta 10 segundos, el
límite de tiempo de solicitud pendiente máximo, antes de que se activen los nuevos inicios de instancia.
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 la aplicación será menor.
min_pending_latency
Elemento opcional que puedes definir para especificar el tiempo mínimo que debe esperar una solicitud en la cola pendiente antes de iniciar una nueva instancia para gestionarla.
Si especifica un valor, puede reducir los costes de ejecución, pero aumentará el tiempo que los usuarios deben esperar para que se atiendan sus solicitudes.
En el caso de las aplicaciones gratuitas, el valor predeterminado es 500ms. En el caso de las aplicaciones de pago, el valor predeterminado es 0.
Este elemento funciona junto con el elemento max_pending_latency
para determinar cuándo crea App Engine nuevas instancias.
Si hay solicitudes pendientes en la cola:
Si es inferior al valor min_pending_latency que especifiques,
App Engine no creará instancias nuevas.
Si se supera este límite, App Engine
intentará crear una instancia.max_pending_latency
Entre la hora especificada por min_pending_latency
y max_pending_latency, App Engine intentará
reutilizar una instancia. Si ninguna instancia puede procesar la solicitud antes de max_pending_latency, App Engine creará una nueva instancia.
Las aplicaciones que usen una clase instance de B1 o una versión posterior deben especificar este elemento o manual_scaling.
Este elemento permite el escalado 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 puede crear para esta versión del servicio. Esto resulta útil para limitar los costes de un servicio.
idle_timeout
Opcional. La instancia se cerrará al cabo de este tiempo después de recibir su última solicitud. El valor predeterminado es 5 minutos
(5m).
Ejemplo
basic_scaling:max_instances:11idle_timeout:10m
manual_scaling
Las aplicaciones que usen una clase instance de B1 o una versión posterior deben especificar este elemento o basic_scaling.
Este elemento permite escalar manualmente las clases de instancia B1 y superiores, y puede contener el siguiente elemento:
instances
Número de instancias que se asignarán al servicio al inicio.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-12 (UTC)."],[],[],null,[]]
