ID da região
O REGION_ID é um código abreviado que o Google atribui
com base na região que você selecionou ao criar o aplicativo. O código não
corresponde a um país ou estado, ainda que alguns IDs de região sejam semelhantes
aos códigos de país e estado geralmente usados. Para apps criados após
fevereiro de 2020, o REGION_ID.r está incluído nos
URLs do App Engine. Para apps existentes criados antes dessa data, o
ID da região é opcional no URL.
Saiba mais sobre IDs de região.
Este documento descreve como um aplicativo do App Engine recebe solicitações e envia respostas.
Para mais detalhes, consulte a referência sobre respostas e cabeçalhos de solicitação.
Caso seu aplicativo use serviços, é possível endereçar solicitações para um serviço específico ou uma determinada versão desse serviço. Para mais informações sobre a capacidade de endereçamento do serviço, consulte Como as solicitações são encaminhadas.
Como processar solicitações
O aplicativo é responsável por iniciar um servidor da Web e processar as solicitações. É possível usar qualquer framework da Web disponível na linguagem de programação adotada.
Várias instâncias do aplicativo são executadas no App Engine, e cada uma tem um servidor da Web próprio para processar as solicitações. Como cada solicitação pode ser encaminhada para qualquer instância, solicitações consecutivas do mesmo usuário não são necessariamente enviadas para a mesma instância. Uma instância pode processar várias solicitações simultaneamente. O número de instâncias pode ser ajustado automaticamente à medida que o tráfego muda.
Também é possível alterar o número de solicitações simultâneas que uma instância processa. Para isso, configure o elemento max_concurrent_requests no arquivo app.yaml.
O servidor determina qual script de gerenciador PHP será executado comparando o URL da
solicitação com os padrões de URL no arquivo de configuração app.yaml
do aplicativo. Em seguida, o script preenchido com os dados da solicitação é executado. Os dados da solicitação são colocados em variáveis de ambiente e no stream de entrada padrão pelo servidor. As ações apropriadas à solicitação são executadas e uma resposta é preparada
e colocada no stream de saída padrão.
O exemplo a seguir é de um script PHP para responder a qualquer solicitação HTTP com a mensagem "Hello World!"
Cotas e limites
No App Engine, os recursos são alocados automaticamente para o aplicativo à medida que o tráfego aumenta. No entanto, isso é limitado pelas seguintes restrições:
O App Engine reserva a capacidade de escalonamento automático para aplicativos com baixa latência, em que a resposta a uma solicitação ocorre em menos de um segundo.
Aplicativos que fazem muito uso da CPU podem gerar mais latência, a fim de compartilhar recursos de maneira eficiente com outros aplicativos nos mesmos servidores. Solicitações de arquivos estáticos estão isentas dos limites de latência.
Cada solicitação recebida para o aplicativo é contabilizada no limite de Solicitações. Os dados enviados em resposta a uma solicitação são contabilizados no limite de Largura de banda de saída (faturável).
Tanto as solicitações HTTP quanto as HTTPS (seguras) são contabilizadas nos limites de Solicitações, Largura de banda de entrada (faturável) e Largura de banda de saída (faturável). A página "Detalhes da cota" do console do Google Cloud também exibe Solicitações seguras, largura de banda de entrada segura e largura de banda de saída segura como valores separados para fins informativos. Apenas solicitações HTTPS são contabilizadas nesses valores. Para mais informações, consulte a página Cotas.
Os limites a seguir se aplicam especificamente ao uso de gerenciadores de solicitações:
| Limite | Valor |
|---|---|
| Tamanho da solicitação | 32 megabytes |
| Tamanho da resposta | 32 megabytes |
| Tempo limite da solicitação | Depende do tipo de escalonamento usado pelo aplicativo |
| Número máximo total de arquivos (arquivos de aplicativos e arquivos estáticos) | 10.000 no total 1.000 por diretório |
| Tamanho máximo de um arquivo de aplicativo | 32 megabytes |
| Tamanho máximo de um arquivo estático | 32 megabytes |
| Tamanho máximo total de todos os arquivos de aplicativo e arquivos estáticos | O primeiro 1 gigabyte é gratuito US$ 0,026 por gigabyte por mês após o primeiro 1 gigabyte |
| Tempo limite da solicitação pendente | 10 segundos |
| Tamanho máximo de um campo de cabeçalho de solicitação único | 8 kilobytes para ambientes de execução de segunda geração no ambiente padrão. As solicitações para esses ambientes de execução com campos de cabeçalho acima de 8 kilobytes retornarão erros HTTP 400. |
Limites de solicitações
Todas as solicitações em HTTP/2 são traduzidas para HTTP/1.1 quando encaminhadas para o servidor do aplicativo.
Limites de respostas
As respostas dinâmicas são limitadas a 32 MB. Se um gerenciador de script gerar uma resposta maior do que esse limite, o servidor devolverá uma resposta vazia com um código de status 500 Erro interno do servidor. Essa limitação não se aplica a respostas que disponibilizam dados do Cloud Storage
O limite de cabeçalho de resposta é de 8 KB para ambientes de execução de segunda geração. Os cabeçalhos de resposta que excederem esse limite retornarão erros HTTP 502, com registros que mostram
upstream sent too big header while reading response header from upstream.
Cabeçalhos de solicitação
Uma solicitação HTTP recebida inclui os cabeçalhos HTTP enviados pelo cliente. Para fins de segurança, alguns cabeçalhos são limpos ou retificados por proxies intermediários antes de chegarem ao aplicativo.
Para mais informações, consulte a referência sobre cabeçalhos de solicitação.
Como processar os tempos limites das solicitações
O App Engine é otimizado para aplicativos com solicitações de curta duração, normalmente aquelas que levam poucas centenas de milissegundos. Aplicativos eficientes respondem com rapidez à maioria das solicitações. Caso contrário, o aplicativo não escalonará bem com a infraestrutura do App Engine. Para garantir esse nível desempenho, há um tempo limite máximo de solicitação imposto pelo sistema para cada aplicativo.
Se um script PHP exceder esse prazo, o bitTIMEOUT no bitfield status da conexão será definido. O script terá então um segundo prazo curto para limpar qualquer tarefa de execução
longa e retornar uma resposta ao usuário.
Se o script não tiver retornado uma resposta no final do segundo prazo, o gerenciador será interrompido e uma resposta de erro padrão será retornada.
Respostas
O App Engine chama o script com a matriz$_REQUEST preenchida,
armazena em buffer qualquer saída do script e, quando a execução do script é concluída,
envia a saída em buffer para o usuário final.
Existem limites de tamanho que se aplicam à resposta gerada. Essa resposta pode ser modificada antes de retornar ao cliente.
Para mais informações, consulte a referência sobre respostas a solicitações.Respostas de streaming
O App Engine não é compatível com respostas de streaming em que os dados são enviados em blocos incrementais para o cliente enquanto uma solicitação está sendo processada. Todos os dados do seu código são coletados conforme descrito acima e enviados como uma única resposta HTTP.
Compactação de resposta
O App Engine faz o possível para exibir conteúdo compactado (gzip) para clientes compatíveis. Para determinar se o conteúdo precisa ser compactado, o App Engine faz o seguinte ao receber uma solicitação:Confirma se o cliente pode receber respostas compactadas de maneira confiável visualizando os cabeçalhos
Accept-EncodingeUser-Agentna solicitação. Esse método evita alguns erros conhecidos com conteúdo compactado com gzip nos navegadores mais conhecidos.Confirma se a compactação do conteúdo é apropriada ao visualizar o cabeçalho
Content-Typeconfigurado para o gerenciador de respostas. Em geral, a compactação é apropriada para tipos de conteúdo baseados em texto, e não para tipos de conteúdo binário.
Observe o seguinte:
Um cliente pode forçar a compactação de tipos de conteúdo baseados em texto definindo os cabeçalhos da solicitação
Accept-EncodingeUser-Agentcomogzip.Se uma solicitação não especificar
gzipno cabeçalhoAccept-Encoding, o App Engine não compactará os dados de resposta.O Google Frontend armazena em cache as respostas dos gerenciadores de arquivo e diretório estáticos do App Engine. Dependendo de diversos fatores, como qual tipo de dados de resposta é armazenado em cache primeiro, quais cabeçalhos
Varysão especificados na resposta e quais cabeçalhos estão incluídos na solicitação, o cliente pode solicitar dados compactados e recebê-los não compactados e vice-versa. Para mais informações, consulte Armazenamento de respostas em cache.
Armazenamento de respostas em cache
O Google Frontend e, possivelmente, o navegador do usuário e outros servidores proxy de cache intermediários armazenarão as respostas do aplicativo em cache, conforme instruído pelos cabeçalhos de armazenamento em cache padrão especificados na resposta. Especifique esses cabeçalhos de resposta por meio do framework, diretamente no seu código ou por meio de gerenciadores de diretórios e arquivos estáticos do App Engine.
No Google Frontend, a chave de cache é o URL completo da solicitação.
Como armazenar conteúdo estático em cache
Para garantir que os clientes sempre recebam conteúdo estático atualizado assim que ele
for publicado, recomendamos exibir conteúdo estático de diretórios com
versão, como css/v1/styles.css. O Google Frontend não validará
o cache (verifique o conteúdo atualizado) até que ele expire. Mesmo após a expiração, ele não será atualizado até que o conteúdo do URL de solicitação seja alterado.
Os seguintes cabeçalhos de resposta que podem ser
definidos em
app.yaml
influenciam como e quando o Google Frontend armazena conteúdo em cache:
Cache-Controlprecisa ser definido comopublicpara que o Google Frontend armazene conteúdo em cache. Ele também pode ser armazenado em cache pelo Google Frontend, a menos que você especifique uma diretivaCache-Controlprivateouno-store. Se você não definir esse cabeçalho emapp.yaml, o App Engine irá adicioná-lo automaticamente a todas as respostas processadas por um gerenciador de arquivo ou diretório estático. Para mais informações, consulte Cabeçalhos adicionados ou substituídos.Vary: para permitir que o cache retorne respostas diferentes para um URL com base nos cabeçalhos enviados na solicitação, defina um ou mais dos seguintes valores no cabeçalho da respostaVary:Accept,Accept-Encoding,OriginouX-OriginDevido ao potencial para alta cardinalidade, os dados não serão armazenados em cache para outros valores de
Vary.Por exemplo:
Especifique o seguinte cabeçalho de resposta:
Vary: Accept-EncodingO aplicativo recebe uma solicitação que contém o cabeçalho
Accept-Encoding: gzip. O App Engine retorna uma resposta compactada e o Google Frontend armazena em cache a versão em gzip dos dados da resposta. Todas as solicitações subsequentes deste URL que contenham o cabeçalhoAccept-Encoding: gzipreceberão os dados compactados em gzip do cache até que ele se torne inválido (devido à alteração do conteúdo após a expiração).O aplicativo recebe uma solicitação que não contém o cabeçalho
Accept-Encoding. O App Engine retorna uma resposta descompactada e o Google Frontend armazena em cache a versão descompactada dos dados de resposta. Todas as solicitações subsequentes deste URL que não contenham o cabeçalhoAccept-Encodingreceberão os dados compactados do cache até que o ele se torne inválido.
Se você não especificar um cabeçalho de resposta
Vary, o Google Frontend criará uma única entrada de cache para o URL e a usará para todas as solicitações, independentemente dos cabeçalhos na solicitação. Por exemplo:- Você não especifica o cabeçalho de resposta
Vary: Accept-Encoding. - Uma solicitação contém o cabeçalho
Accept-Encoding: gzipe a versão compactada em gzip dos dados de resposta será armazenada em cache. - Uma segunda solicitação não contém o cabeçalho
Accept-Encoding: gzip. No entanto, como o cache contém uma versão compactada em gzip dos dados de resposta, a resposta será compactada, mesmo que o cliente tenha solicitado dados descompactados.
Os cabeçalhos da solicitação também influenciam o armazenamento em cache:
- Se a solicitação contiver um cabeçalho
Authorization, o conteúdo não será armazenado em cache pelo Google Frontend.
Expiração do cache
Por padrão, os cabeçalhos de armazenamento em cache que gerenciadores de arquivo e diretório estáticos do App Engine adicionam às respostas instruem os clientes e os proxies da Web, como o Google Frontend, a expirar o cache após 10 minutos.
Depois que um arquivo é transmitido com um prazo de validade determinado, geralmente, não há como removê-lo de caches de proxy da Web, mesmo que o usuário limpe seu próprio cache do navegador. A reimplantação de uma nova versão do aplicativo não redefinirá nenhum cache. Portanto, se você planeja modificar um arquivo estático, ele deve ter um tempo de expiração curto (menos de uma hora). Na maioria dos casos, o prazo de validade padrão de 10 minutos é suficiente.
É possível alterar a expiração padrão de todos os gerenciadores de arquivos e diretórios estáticos
especificando o elemento
default_expiration
no
arquivo
app.yaml. Para definir prazos de validade específicos para
gerenciadores
individuais, especifique o elemento expiration
dentro do elemento do gerenciador no
arquivo
app.yaml.
O valor especificado no tempo de expiração dos elementos será usado para
definir os cabeçalhos de resposta HTTP Cache-Control e Expires.
Armazenamento em cache do app
O ambiente de execução do PHP inclui o OPcache, que pode armazenar em cache o código intermediário do PHP e melhorar significativamente o tempo de resposta do aplicativo. É possível desativar o armazenamento em cache do OPcache definindoopcache.enabled = "0" no
arquivo php.ini
do aplicativo.
Logging
O servidor da web do App Engine captura tudo que o script de gerenciador grava no fluxo de saída padrão para a resposta à solicitação da Web. Ele também captura tudo que o script de gerenciador grava no fluxo de erros padrão e armazena isso como dados de registro. Os dados de registro do aplicativo podem ser visualizados no Console do Google Cloud usando o Cloud Logging.O ambiente de execução PHP do App Engine inclui suporte para registrar
mensagens arbitrárias do aplicativo usando a função
syslog() integrada do PHP, que invoca a
API Logs.
Ambiente
Como forçar conexões HTTPS
Por motivos de segurança, todos os aplicativos precisam incentivar os clientes a
se conectar por https. Para instruir o navegador a preferir https a http em uma determinada página
ou em todo o domínio, defina o cabeçalho Strict-Transport-Security nas respostas.
Por exemplo:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Como gerenciar o trabalho em segundo plano assíncrono
O trabalho em segundo plano é qualquer trabalho que seu aplicativo execute para uma solicitação depois de ter entregado a resposta HTTP. Evite executar trabalhos em segundo plano no aplicativo e revise seu código para verificar se todas as operações assíncronas foram concluídas antes de enviar a resposta.
Para jobs de longa duração, recomendamos o uso do Cloud Tasks. Com o Cloud Tasks, as solicitações HTTP têm longa duração e retornam uma resposta somente após o término de qualquer trabalho assíncrono.