Cómo se manejan las solicitudes

ID de región

REGION_ID es un código abreviado que Google asigna en función de la región que seleccionas cuando creas tu app. El código no corresponde a un país o provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia de uso común. Incluir REGION_ID.r en las URL de App Engine es opcional para las apps existentes, y pronto será obligatorio para todas las apps nuevas.

A fin de garantizar una transición sin problemas, estamos actualizando App Engine con lentitud para usar los ID de región. Si aún no actualizamos tu proyecto de Google Cloud, no verás un ID de región para la app. Dado que el ID es opcional para las apps existentes, no necesitas actualizar las URL ni realizar otros cambios una vez que el ID de región esté disponible para las apps existentes.

Obtén más información acerca de los ID de región.

En este documento se describe cómo tu aplicación de App Engine recibe solicitudes y envía respuestas. Para obtener más detalles, consulta la referencia de encabezados de solicitud y respuestas.

Si tu aplicación usa servicios, puedes dirigir solicitudes a un servicio específico o a una versión específica de ese servicio. Para obtener más información sobre cómo direccionar el servicio, consulta Cómo enrutar solicitudes.

Cómo controlar las solicitudes

La aplicación se encarga de iniciar un servidor web y controlar las solicitudes. Puedes usar cualquier marco de trabajo web que esté disponible para tu lenguaje de desarrollo.

App Engine ejecuta varias instancias de tu aplicación, y cada una tiene su propio servidor web para manejar solicitudes. Estas pueden enrutarse a cualquier instancia, por lo que las solicitudes consecutivas del mismo usuario no necesariamente se envían a la misma instancia. Una instancia puede manejar varias solicitudes al mismo tiempo. La cantidad de instancias se puede ajustar de forma automática a medida que cambia el tráfico. También puedes cambiar la cantidad de solicitudes simultáneas que puede controlar una instancia si configuras el elemento max_concurrent_requests en el archivo app.yaml.

El servidor determina qué secuencia de comandos del controlador debe ejecutar PHP. Para hacerlo, compara la URL de la solicitud y los patrones de URL del archivo de configuración app.yaml de la app. Luego, ejecuta la secuencia de comandos que contiene los datos solicitados. El servidor coloca los datos de la solicitud en las variables del entorno y en el flujo de entrada estándar. La secuencia de comandos realiza las acciones adecuadas para la solicitud y, luego, prepara una respuesta y la coloca en el flujo de salida estándar.

El siguiente ejemplo es una secuencia de comandos PHP que responde a cualquier solicitud HTTP con el mensaje “Hello World!”

<?php

echo "hello world!";

El siguiente ejemplo usa el marco de trabajo Slim para responder a una solicitud HTTP.

$app = new Slim\App();
$app->get('/', function ($request, $response) {
    // Use the Null Coalesce Operator in PHP7
    // http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.coalesce
    $name = $request->getQueryParams()['name'] ?? 'World';
    return $response->getBody()->write("Hello, $name!");
});
$app->run();

Cuotas y límites

App Engine asigna recursos a tu aplicación de manera automática a medida que el tráfico aumenta. Sin embargo, esto se limita con las siguientes restricciones:

  • App Engine reserva la capacidad de ajuste de escala automático para aplicaciones con latencia baja a fin de que la aplicación responda a las solicitudes en menos de un segundo. Las aplicaciones con latencia muy alta, como las de más de un segundo por solicitud para varias solicitudes, y con capacidad de procesamiento alta requieren asistencia nivel Plata, Oro o Platino. Los clientes con este nivel de asistencia pueden comunicarse con su representante de asistencia para solicitar el aumento de sus límites de capacidad de procesamiento.

  • Las aplicaciones estrechamente vinculadas a la CPU también pueden incurrir en alguna latencia adicional para compartir recursos de manera eficaz con otras aplicaciones en el mismo servidor. Las solicitudes para archivos estáticos están exentas de estos límites de capacidad de latencia.

Cada solicitud que entra a la aplicación se tiene en cuenta para los límites de Solicitudes. Los datos enviados en respuesta a una solicitud se tienen en cuenta para el límite de Ancho de banda de salida (facturable).

Tanto las solicitudes HTTP como las HTTPS (seguras) se tienen en cuenta para los límites de Solicitudes, Ancho de banda de entrada (facturable) y Ancho de banda de salida (facturable). La página Detalles de cuota de Cloud Console también informa las Solicitudes seguras, el Ancho de banda de entrada seguro y el Ancho de banda saliente seguro como valores separados. Solo se tienen en cuenta las solicitudes HTTPS para estos valores. Para obtener más información, consulta la página de Cuotas.

Los siguientes límites se aplican específicamente al uso de los controladores de solicitudes:

Límite Importe
tamaño de la solicitud 32 megabytes
tamaño de la respuesta 32 megabytes
Tiempo de espera de la solicitud depende del tipo de escalamiento que use la app
cantidad total máxima de archivos (archivos estáticos y de la app) 10,000 en total
1,000 por directorio
tamaño máximo de un archivo de la aplicación 32 megabytes
tamaño máximo de un archivo estático 32 megabytes
tamaño total máximo de todos los archivos estáticos y de la aplicación el primer gigabyte es gratis
$0.026 por gigabyte por mes después del primer gigabyte

Límites de la respuesta

Las respuestas dinámicas tienen un límite de 32 MB. Si un controlador de secuencia de comandos genera una respuesta superior a este límite, el servidor envía una respuesta vacía con un código de estado 500 “Error interno del servidor”. Esta limitación no se aplica a las respuestas que entregan datos desde Cloud Storage.

Encabezados de solicitud

Una solicitud HTTP nueva incluye los encabezados HTTP que envía el cliente. Por motivos de seguridad, los proxies intermedios limpian o modifican algunos encabezados antes de que lleguen a la aplicación.

Para obtener más información, consulta la referencia de Encabezados de solicitud.

Respuestas a solicitudes

App Engine llama a la secuencia de comandos con el arreglo $_REQUEST propagado, almacena en el búfer cualquier resultado de la secuencia de comandos y, cuando está completa la ejecución, envía el resultado almacenado en búfer al usuario final.

Se aplican límites a la respuesta que generas y la respuesta se puede modificar antes de que regrese al cliente.

Para obtener más información, consulta la referencia de respuestas a solicitudes.

Respuestas a transmisión

App Engine no admite la transmisión de respuestas, donde los datos se envían en fragmentos graduales al cliente mientras se procesa una solicitud. Todos los datos de tu código se recopilan como se describió anteriormente y se envían como una respuesta HTTP simple.

Compresión de la respuesta

Si el cliente envía encabezados HTTP con la solicitud original que indican que el cliente puede aceptar contenido comprimido (en formato Gzip), App Engine comprime automáticamente los datos de respuesta del controlador y adjunta los encabezados de respuesta adecuados. Usa los encabezados de solicitud Accept-Encoding y User-Agent para determinar si el cliente puede recibir respuestas comprimidas de manera confiable.

Los clientes personalizados pueden indicar la posibilidad de recibir respuestas comprimidas si especifican los encabezados Accept-Encoding y User-Agent con el valor gzip. El Content-Type de la respuesta también se usa para determinar si es adecuado usar la compresión. Por lo general, los tipos de contenido basado en texto están comprimidos, mientras que los tipos de contenido binario no lo están.

Cuando App Engine comprime las respuestas automáticamente, el encabezado Content-Encoding se agrega a la respuesta.

Especifica un plazo de solicitud

App Engine está optimizado para aplicaciones con solicitudes de corta duración, que son por lo general las que tardan unos cientos de milisegundos. Una app eficiente responde con rapidez a la mayoría de las solicitudes. Si una app no puede hacerlo, no escalará bien con la infraestructura de App Engine.

Una secuencia de comandos PHP tiene un tiempo limitado para generar y mostrar una respuesta a una solicitud. Una vez que se cumple el plazo, se establece el bit TIMEOUT en el campo de bits de estado de la conexión. Tu secuencia de comandos tendrá un segundo plazo para limpiar las tareas de larga duración y mostrar una respuesta al usuario.

Si tu secuencia de comandos no muestra una respuesta antes del segundo plazo, el controlador se cierra y se muestra una respuesta de error predeterminada.

Almacenamiento en caché de las apps

El entorno de ejecución PHP incluye OPcache, que puede almacenar el código intermedio PHP en caché y mejorar de manera significativa el tiempo de respuesta de la aplicación. Puedes inhabilitar el almacenamiento en caché de OPcache si configuras opcache.enabled = "0" en el archivo php.ini de la aplicación.