O Go 1.11 atingiu o fim do apoio técnico
e vai ser descontinuado
a 31 de janeiro de 2026. Após a descontinuação, não vai poder implementar aplicações Go 1.11, mesmo que a sua organização tenha usado anteriormente uma política organizacional para reativar as implementações de runtimes antigos. As suas aplicações Go 1.11 existentes vão continuar a ser executadas e a receber tráfego após a data de descontinuação. Recomendamos que migre para a versão suportada mais recente do Go.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
ID da região
O REGION_ID é um código abreviado que a Google atribui com base na região que seleciona quando cria a sua app. O código não corresponde a um país ou uma província, embora alguns IDs de regiões possam parecer semelhantes aos códigos de países e províncias usados frequentemente. Para apps criadas após
fevereiro de 2020, REGION_ID.r está incluído nos
URLs do App Engine. Para apps existentes criadas antes desta data, o
ID da região é opcional no URL.
Configura as definições da app do App Engine no ficheiro app.yaml.
O ficheiro app.yaml também contém informações sobre o código da sua app, como o tempo de execução e o identificador da versão mais recente.
Cada serviço
na sua app tem o seu próprio ficheiro app.yaml, que funciona como um descritor para a respetiva
implementação. Primeiro, tem de criar o ficheiro app.yaml para o serviço default antes de poder criar e implementar ficheiros app.yaml para serviços adicionais na sua app.
Para o Go 1.11, o app.yaml tem de conter, pelo menos, uma entrada runtime. Para uma breve vista geral, consulte o artigo Definir definições de tempo de execução.
Estrutura do diretório
A pasta de cada serviço tem de conter um ficheiro app.yaml e um ou mais ficheiros de origem Go que incluam a declaração package main no início.
Para saber como estruturar vários serviços na sua app, consulte o artigo
Estruturar serviços Web no App Engine.
Exemplo
Segue-se um exemplo de um ficheiro app.yaml para uma aplicação Go 1.11:
O formato YAML suporta comentários. Uma linha que começa com um caráter de cardinal (#) é ignorada:
# This is a comment.
Os padrões de URL e caminho do ficheiro usam a sintaxe de expressão regular estendida POSIX, excluindo elementos de ordenação e classes de ordenação. As referências anteriores a correspondências agrupadas (por exemplo, \1) são suportadas, tal como estas extensões Perl: \w \W \s \S \d \D.
Tempo de execução e elementos da app
Elemento
Descrição
build_env_variables
Opcional. Se estiver a usar um tempo de execução que suporte
buildpacks, pode
definir variáveis de ambiente de compilação no seu
ficheiro app.yaml.
Opcional. Define um período de cache predefinido global para todos os controladores de ficheiros estáticos de uma aplicação. Também pode configurar uma duração da cache para gestores de ficheiros estáticos específicos. O valor é uma string de números e unidades, separados por
espaços, em que as unidades podem ser d para dias, h para horas, m para minutos e
s para segundos. Por exemplo, "4d 5h" define a expiração da cache
para 4 dias e 5 horas após o ficheiro ser pedido pela primeira vez. Se for omitido,
o servidor de produção define a expiração para 10 minutos.
Opcional.
Substitui o comportamento de arranque predefinido executando o comando entrypoint quando a app é iniciada. Para que a sua app receba pedidos HTTP, o elemento entrypoint deve conter um comando que inicie um servidor Web que escute na porta 8080.
env_variables
Opcional.
Pode definir variáveis de ambiente no ficheiro app.yaml
para as disponibilizar à sua app. Certifique-se de que a chave em Variáveis de ambiente corresponde à expressão "[a-zA-Z_][a-zA-Z0-9_]*" (começar com um alfabeto ou "_" seguido de qualquer carater alfanumérico ou "_").
As variáveis de ambiente com o prefixo
GAE estão reservadas para utilização do sistema e não são permitidas no ficheiro
app.yaml.
Exemplo:
env_variables:MY_VAR:"myvalue"
onde MY_VAR e my value são o nome e o
valor da variável de ambiente que quer definir, e cada
entrada da variável de ambiente tem uma indentação de dois espaços abaixo do
elemento env_variables. As variáveis de ambiente às quais não é atribuído um valor têm como predefinição "None".
Em seguida, pode obter estes valores através de os.Getenv:
Publicado se for atingido um prazo antes de haver uma resposta da sua app.
O error_code é opcional. Se não for especificado, o ficheiro indicado é a resposta de erro predefinida para a sua app.
file
Cada entrada de ficheiro indica um ficheiro estático que deve ser publicado em
vez da resposta de erro genérica. Se especificar um elemento
file sem um elemento
error_code correspondente, o ficheiro estático é a página de erro
predefinida para a sua app.
Os dados de erro personalizados têm de ter menos de 10 kilobytes.
Opcional.
Uma lista de padrões de URL e descrições de como devem ser processados.
O App Engine pode processar URLs executando código de aplicação ou
publicando ficheiros estáticos carregados com o código, como imagens, CSS ou
JavaScript.
Opcional.
As aplicações têm de ativar esses serviços antes de poderem receber pedidos
de entrada. Pode ativar o serviço para uma app Go 1.11
incluindo uma secção inbound_services no ficheiro
app.yaml.
Os seguintes valores estão disponíveis consoante o
dimensionamento do seu serviço:
Escala automática
F1, F2, F4, F4_1G
Predefinição:F1
Opcionalmente, use o elemento automatic_scaling para alterar as predefinições
da escalabilidade automática, como o número mínimo e máximo
de instâncias, a latência e as ligações simultâneas.
Nota: se instance_class
estiver definido como F2 ou superior, pode otimizar as suas instâncias
definindo max_concurrent_requests para um valor superior ao
valor predefinido de 10. Para determinar o valor ideal,
aumente-o gradualmente e monitorize o desempenho da sua
aplicação.
Dimensionamento básico e manual
B1, B2, B4, B4_1G, B8
Predefinição:B2
As classes de instâncias básicas e manuais requerem que especifique o elemento basic_scaling ou o elemento manual_scaling.
Opcional.
O caminho ou o nome do pacote totalmente qualificado do pacote principal. Esta
definição só se aplica se a sua app usar o modo de módulo Go.
Tem de declarar o caminho para o pacote principal se o seu
package main não estiver no mesmo diretório que o seu
app.yaml. O elemento main suporta caminhos de ficheiros relativos a app.yaml ou nomes de pacotes completos. Por
exemplo, se a sua app tiver esta estrutura de diretórios:
Obrigatório. O nome do ambiente de tempo de execução usado pela sua app. Por exemplo, para especificar Go 1.11, use:
runtime:go111
service
Obrigatório se estiver a criar um
serviço.
Opcional para o serviço default. Cada serviço e cada versão têm de ter um nome. Um nome pode
conter números, letras e hífenes. O comprimento combinado de
VERSION-dot-SERVICE-dot-PROJECT_ID, em que VERSION é o nome da
sua versão, SERVICE é o nome do seu serviço e PROJECT_ID
é o ID do seu projeto, não pode exceder 63 carateres e não pode
começar nem terminar com um hífen. Escolha um nome exclusivo para cada serviço
e cada versão. Não reutilize nomes entre serviços e versões.
Exemplo:
service:service-name
service_account
Opcional. O elemento service_account permite-lhe especificar uma
conta de serviço gerida pelo utilizador como a identidade da versão. A conta de serviço especificada é usada quando acede a outros Google Cloud serviços e executa tarefas.
Opcional.
Configura a sua aplicação para usar um conetor do Acesso a VPC sem servidor, o que permite à aplicação enviar pedidos a recursos internos na sua rede VPC. Para mais informações, consulte o artigo
Estabelecer ligação a uma rede VPC.
name
Literal de string. Especifique o nome totalmente qualificado do seu conetor de acesso à VPC sem servidor entre aspas:
Opcional. A predefinição é private-ranges-only. O elemento
egress_setting pode ser um dos seguintes:
private-ranges-only
Predefinição. Os pedidos a endereços IP internos são enviados através do conetor de acesso a VPC sem servidor para a rede VPC associada. Os pedidos para endereços IP
externos são enviados para a Internet pública.
all-traffic
Todos os pedidos são enviados através do conetor de acesso a VPC sem servidor para a rede VPC ligada.
O elemento handlers fornece uma lista de padrões de URL e descrições de como devem ser processados. O App Engine pode processar URLs executando código de aplicação ou publicando ficheiros estáticos carregados com o código, como imagens, CSS ou JavaScript.
Os padrões são avaliados pela ordem em que aparecem no ficheiro app.yaml, de cima para baixo. O primeiro mapeamento cujo padrão corresponde ao URL é o que é usado para processar o pedido.
A tabela seguinte lista os subelementos do elemento handlers que controlam o comportamento dos scripts, ficheiros estáticos, diretórios estáticos e outras definições.
Elemento
Descrição
auth_fail_action
Opcional.
Descreve a ação realizada quando o elemento login é especificado para um controlador e o utilizador não tem sessão iniciada. Tem dois valores possíveis:
redirect
Predefinição. O utilizador é redirecionado para a página de início de sessão do Google ou
/_ah/login_required se for usada a autenticação OpenID.
O utilizador é redirecionado novamente para o URL da aplicação depois de iniciar sessão
ou criar uma conta.
unauthorized
O pedido é rejeitado com um código de estado HTTP 401
e uma mensagem de erro.
Se uma aplicação precisar de um comportamento diferente, a própria aplicação pode
implementar o processamento dos inícios de sessão dos utilizadores. Consulte a API Users para mais informações.
O exemplo seguinte requer um início de sessão para o diretório /profile/
e um início de sessão de administrador para o diretório /admin/:
Pode configurar um controlador para recusar o acesso a URLs protegidos quando
o utilizador não tem sessão iniciada, em vez de o redirecionar para a
página de início de sessão, adicionando auth_fail_action: unauthorized à
configuração do controlador:
expiration
Opcional.
O período durante o qual um ficheiro estático publicado por este controlador deve ser colocado em cache por proxies Web e navegadores. O valor é uma string de números e unidades, separados por espaços, em que as unidades podem ser d para dias, h para horas, m para minutos e s para segundos. Por exemplo,
"4d 5h" define a expiração da cache para 4 dias e 5 horas após
o ficheiro ser pedido pela primeira vez. Se for omitido, é usado o valor default_expiration da aplicação. Consulte Expiração da cache para mais detalhes.
http_headers
Opcional. Pode definir cabeçalhos HTTP para respostas dos processadores de diretórios ou ficheiros estáticos. Se precisar de definir cabeçalhos HTTP
nos seus processadores script, deve fazê-lo no código
da sua app. Para obter informações sobre os cabeçalhos de resposta que influenciam o armazenamento em cache,
consulte o artigo Armazenamento em cache
de conteúdo estático.
Uma utilização importante desta funcionalidade é suportar a partilha de recursos de origem cruzada (CORS), como aceder a ficheiros alojados por outra app do App Engine.
Por exemplo, pode ter uma app de jogos mygame.uc.r.appspot.com
que acede a recursos alojados por myassets.uc.r.appspot.com.
No entanto, se mygame tentar fazer um pedido JavaScript
XMLHttpRequest para myassets, não vai
ter êxito, a menos que o controlador de myassets devolva um cabeçalho de resposta
Access-Control-Allow-Origin: que contenha o valor http://mygame.uc.r.appspot.com.
Veja como faria com que o seu controlador de ficheiros estáticos devolvesse esse valor do cabeçalho da resposta obrigatório:
Nota: se quiser permitir que todos acedam aos seus recursos, pode usar o caráter universal '*' em vez de https://mygame.uc.r.appspot.com.
login
Opcional.
Determina se o controlador de URL requer que o utilizador tenha sessão iniciada.
Este elemento tem três valores possíveis:
optional
Predefinição. Não requer que o utilizador tenha sessão iniciada.
required
Se o utilizador tiver iniciado sessão, o controlador prossegue normalmente. Caso contrário,
é realizada a ação indicada em auth_fail_action.
admin
Tal como com required, executa auth_fail_action
se o utilizador não tiver sessão iniciada. Além disso, se o utilizador não for um
administrador da aplicação, recebe uma mensagem de erro
independentemente da definição de auth_fail_action. Se o utilizador for um administrador, o controlador continua.
Quando um controlador de URL com uma definição login diferente de
optional corresponde a um URL, o controlador verifica primeiro se o utilizador iniciou sessão na aplicação através da respetiva
opção de autenticação. Caso contrário, por predefinição, o utilizador é redirecionado
para a página de início de sessão. Também pode usar auth_fail_action para
configurar a app para rejeitar simplesmente pedidos de um controlador de utilizadores
que não estejam devidamente autenticados, em vez de redirecionar o utilizador para
a página de início de sessão.
Nota: a adminrestrição de início de sessão também é satisfeita para
pedidos internos para os quais o App Engine define os
cabeçalhos especiais X-Appengineadequados. Por exemplo,
as tarefas agendadas satisfazem a restrição admin, porque o App Engine define um cabeçalho HTTP
X-Appengine-Cron: true nos pedidos respetivos.cron
No entanto, os pedidos não satisfazem a restrição de início de sessão required, porque as tarefas agendadas do cron não são executadas como nenhum utilizador.
mime_type
Opcional. Se for especificado, todos os ficheiros publicados por este controlador vão ser publicados com o tipo MIME especificado. Se não for especificado, o tipo MIME
de um ficheiro é derivado da extensão do nome de ficheiro.
Se o mesmo ficheiro for carregado com várias extensões, a extensão resultante pode depender da ordem em que os carregamentos ocorreram.
Opcional. redirect_http_response_code é usado com a definição secure para definir o código de resposta HTTP devolvido quando é feito um redirecionamento exigido pela forma como a definição secure está configurada.
O elemento redirect_http_response_code tem os seguintes
valores possíveis:
301
Código de resposta
Movido permanentemente.
302
Código de resposta encontrado.
303
Consulte o código de resposta Other.
307
Código de resposta de redirecionamento temporário.
Quando o pedido de um utilizador é redirecionado, o código de estado HTTP é definido
para o valor do parâmetro redirect_http_response_code. Se o parâmetro não estiver presente, é devolvido 302.
script
Opcional.
Especifica que os pedidos ao controlador específico devem segmentar a sua app. O único valor aceite para o elemento script é auto, porque todo o tráfego é publicado através do comando de ponto de entrada. Para usar processadores estáticos, pelo menos um dos seus processadores tem de conter a linha script: auto ou definir um elemento entrypoint para a implementação ser bem-sucedida.
Opcional. Qualquer controlador de URL pode usar a definição secure, incluindo controladores de scripts e controladores de ficheiros estáticos. O elemento secure tem os seguintes
valores possíveis:
optional
Os pedidos HTTP e HTTPS com URLs que correspondem ao controlador
são bem-sucedidos sem redirecionamentos. A aplicação pode examinar o pedido
para determinar que protocolo foi usado e responder em conformidade. Esta é a predefinição quando secure não é fornecido para um controlador.
never
As solicitações de um URL que corresponda a este controlador que use HTTPS são
automaticamente redirecionadas para o URL HTTP equivalente. Quando um pedido HTTPS de um utilizador é redirecionado para ser um pedido HTTP, os parâmetros de consulta são removidos do pedido. Isto impede que um utilizador envie acidentalmente dados de consulta através de uma ligação não segura destinada a uma ligação segura.
always
Os pedidos de um URL que corresponda a este controlador e que não usem HTTPS são
automaticamente redirecionados para o URL HTTPS com o mesmo caminho. Os parâmetros de consulta são preservados para o redirecionamento.
Para
segmentar uma versão específica da sua app através do domínio
REGION_ID.r.appspot.com, substitui os pontos que normalmente separariam os
componentes do subdomínio do URL pela string "-dot-",
por exemplo: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
O início e o fim de sessão nas Contas Google são sempre realizados através de uma ligação segura, independentemente da forma como os URLs da aplicação estão configurados.
static_dir
Opcional. O caminho para o diretório que contém os ficheiros estáticos, a partir do diretório raiz da aplicação. Tudo o que estiver após o final do padrão url correspondente é anexado a static_dir para formar o caminho completo para o ficheiro pedido.
Cada ficheiro no diretório estático é publicado com o tipo MIME que
corresponde à extensão do nome de ficheiro, a menos que seja substituído pela
definição mime_type do diretório. Todos os ficheiros no diretório
indicado são carregados como ficheiros estáticos e
nenhum deles pode ser executado como scripts.
Exemplo:
handlers:# All URLs beginning with /stylesheets are treated as paths to# static files in the stylesheets/ directory.-url:/stylesheetsstatic_dir:stylesheets# ...
static_files
Opcional. Um controlador de padrões de ficheiros estáticos associa um padrão de URL a caminhos para ficheiros estáticos carregados com a aplicação. A expressão regular do padrão de URL pode definir agrupamentos de expressões regulares a usar na construção do caminho do ficheiro. Pode usar isto em vez de
static_dir para mapear ficheiros específicos numa estrutura de diretórios
sem mapear o diretório completo.
Exemplo:
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)$# ...
Os ficheiros estáticos não podem ser iguais aos ficheiros de código da aplicação.
upload
Opcional. Uma expressão regular que corresponde aos caminhos dos ficheiros de todos os ficheiros que vão ser referenciados por este controlador. Isto é necessário porque o controlador não consegue determinar que ficheiros no diretório da sua aplicação correspondem aos padrões url e static_files indicados. Os ficheiros estáticos são carregados e
processados separadamente dos ficheiros da aplicação. O exemplo
acima pode usar o seguinte padrão upload:
archives/(.*)/items/(.*)
url
Elemento obrigatório em handlers. O padrão de URL, como uma expressão regular. A expressão pode conter agrupamentos que podem ser
referidos no caminho do ficheiro para o script com referências
anteriores de expressões regulares. Por exemplo,
/profile/(.*)/(.*) corresponderia ao URL
/profile/edit/manager e usaria
edit e manager como o primeiro e o segundo
agrupamentos.
O padrão de URL tem algumas diferenças no comportamento quando usado com os seguintes elementos:
Usa um prefixo de URL. O padrão de expressão regular não deve conter agrupamentos quando usado com o elemento static_dir. Todos os URLs que começam com este prefixo são processados por este controlador, usando a parte do URL após o prefixo como parte do caminho do ficheiro.
Um controlador de padrões de ficheiros estáticos associa um padrão de URL a caminhos para
ficheiros estáticos carregados com a aplicação. A expressão regular do padrão de URL pode definir agrupamentos de expressões regulares a usar na construção do caminho do ficheiro. Pode usar isto em vez de
static_dir para mapear ficheiros específicos numa estrutura de diretórios
sem mapear o diretório completo.
Dimensionar elementos
Os elementos na tabela seguinte configuram a forma como a sua aplicação é dimensionada. Para saber mais sobre como as apps do App Engine são dimensionadas, consulte os tipos de dimensionamento.
Elemento
Descrição
automatic_scaling
Opcional. Aplicável apenas a aplicações que usam uma
instância
da classe F1 ou superior.
Especifique este elemento para alterar as predefinições do dimensionamento automático, como a definição dos níveis mínimo e máximo para o número de instâncias, a latência e as ligações simultâneas para um serviço.
Este elemento pode conter os seguintes elementos:
max_instances
Opcional. Especifique um valor entre 0 e 2147483647, em que zero
desativa a definição.
Este parâmetro especifica o número máximo de instâncias que o App
Engine deve criar para esta versão do módulo. Isto é útil para limitar os custos de um módulo.
min_instances
Opcional. O número mínimo de instâncias que o App Engine deve criar para esta versão do módulo. Estas instâncias publicam tráfego quando
chegam pedidos e continuam a publicar tráfego mesmo quando
são iniciadas instâncias adicionais, conforme necessário, para processar o tráfego.
Especifique um valor de 0 a 1000. Pode definir
o parâmetro para o valor 0 para permitir o dimensionamento para 0 instâncias de modo a
reduzir os custos quando não estiverem a ser processados pedidos. Tenha em atenção que lhe é cobrado o número de instâncias especificado, quer estejam a receber tráfego ou não.
max_idle_instances
Opcional. O número máximo de instâncias inativas que o App Engine deve manter para esta versão. Especifique um valor de 1 a 1000. Se não for especificado, o valor predefinido é automatic, o que significa que o App Engine vai gerir o número de instâncias inativas.
Tenha em atenção o seguinte:
Um valor máximo elevado reduz o número de instâncias inativas de forma mais
gradual quando os níveis de carga voltam ao normal após um pico. Isto
ajuda a sua aplicação a manter um desempenho estável através das
flutuações na carga de pedidos, mas também aumenta o número de instâncias
inativas (e os custos de execução consequentes) durante esses períodos de
carga elevada.
Um valor máximo baixo mantém os custos de funcionamento mais baixos, mas pode degradar o desempenho perante níveis de carga voláteis.
Nota: quando regressa aos níveis normais após um aumento repentino da carga, o número de instâncias inativas pode exceder temporariamente o máximo especificado. No entanto, não lhe são cobradas mais instâncias do que o número máximo especificado.
min_idle_instances
Opcional: o número de instâncias adicionais a manter em execução
e prontas para publicar tráfego para esta versão.
O App Engine calcula o número de instâncias necessárias para
servir o tráfego atual da sua aplicação com base nas definições de
dimensionamento, como target_cpu_utilization e
target_throughput_utilization. A definição de min_idle_instances
especifica o número de instâncias a
executar além deste número calculado. Por exemplo, se o App Engine calcular que são necessárias 5 instâncias para publicar tráfego e min_idle_instances estiver definido como 2, o App Engine vai executar 7 instâncias (5, calculadas com base no tráfego, mais 2 adicionais por min_idle_instances).
Tenha em atenção que lhe é cobrado o número de instâncias especificado, quer estejam a receber tráfego ou não. Tenha em atenção o seguinte:
Um mínimo baixo ajuda a manter os custos de funcionamento baixos durante os períodos de inatividade, mas significa que podem estar imediatamente disponíveis menos instâncias para responder a um pico de carga súbito.
Um mínimo elevado permite preparar a aplicação para picos rápidos na carga de pedidos. O App Engine mantém o número mínimo de instâncias em execução para atender a pedidos recebidos. O número de instâncias especificado é cobrado, quer estejam ou não a processar pedidos.
Se definir um número mínimo de instâncias inativas, a latência pendente
terá menos efeito no desempenho da sua aplicação.
target_cpu_utilization
Opcional. Especifique um valor entre 0,5 e 0,95. A predefinição é
0.6.
Este parâmetro especifica o limite de utilização da CPU no qual são iniciadas novas instâncias para processar o tráfego, o que lhe permite equilibrar o desempenho e o custo. Os valores mais baixos aumentam o desempenho e o custo, enquanto os valores mais elevados diminuem o desempenho e o custo. Por exemplo, um valor de 0,7 significa que são iniciadas novas instâncias depois de a utilização da CPU atingir 70%.
target_throughput_utilization
Opcional. Especifique um valor entre 0,5 e 0,95. A predefinição é
0.6.
Usado com max_concurrent_requests para especificar quando
uma nova instância é iniciada devido a pedidos simultâneos. Quando o número de pedidos simultâneos atinge um valor igual a max_concurrent_requests vezes target_throughput_utilization, o programador tenta iniciar uma nova instância.
max_concurrent_requests
Opcional. O número de pedidos simultâneos que uma instância de escalamento automático pode aceitar antes de o programador gerar uma nova instância (predefinição: 10, máximo: 1000).
Usado com target_throughput_utilization para
especificar quando uma nova instância é iniciada devido a pedidos simultâneos.
Quando o número de pedidos simultâneos atinge um valor igual a
max_concurrent_requests vezes
target_throughput_utilization, o agendador tenta
iniciar uma nova instância.
Recomendamos que não defina max_concurrent_requests
para menos de 10, a menos que precise de processamento de linha única. Um valor
inferior a 10 provavelmente vai resultar na criação de mais instâncias do que o necessário para uma app segura para vários processos, o que pode gerar custos desnecessários.
Se esta definição for demasiado elevada, pode verificar um aumento da latência da API. Tenha em atenção que o agendador pode gerar uma nova instância antes de atingir o número máximo real de pedidos.
max_pending_latency
O período máximo durante o qual o App Engine deve permitir que um pedido aguarde na fila pendente antes de iniciar instâncias adicionais para processar pedidos, de modo a reduzir a latência pendente. Quando este limite é atingido, é um sinal para aumentar a escala e resulta num aumento do número de instâncias.
Se não for especificado, o valor predefinido é automatic. Isto significa que os pedidos podem permanecer na fila pendente durante um máximo de 10 segundos, o
limite de tempo de pedido pendente máximo, antes de serem acionados novos inícios de instâncias.
Um valor máximo baixo significa que o App Engine inicia novas instâncias
mais cedo para pedidos pendentes, o que melhora o desempenho, mas aumenta
os custos de execução.
Um valor máximo elevado significa que os utilizadores podem esperar mais tempo pela publicação dos respetivos pedidos (se existirem pedidos pendentes e nenhuma instância inativa para os publicar), mas a execução da sua aplicação custa menos.
min_pending_latency
Um elemento opcional que pode definir para especificar a quantidade mínima de tempo que o App Engine deve permitir que um pedido aguarde na fila pendente antes de iniciar uma nova instância para o processar.
A especificação de um valor pode reduzir os custos de funcionamento, mas aumenta o tempo que os utilizadores têm de esperar que os respetivos pedidos sejam processados.
Para apps gratuitas, o valor predefinido é 500ms. Para apps pagas, o valor predefinido é 0.
Este elemento funciona em conjunto com o elemento max_pending_latency
para determinar quando o App Engine cria novas instâncias.
Se existirem pedidos pendentes na fila:
Inferior ao valor min_pending_latency especificado,
o App Engine não cria novas instâncias.
Mais de max_pending_latency, o App Engine
tenta criar uma nova instância.
Entre a hora especificada por min_pending_latency
e max_pending_latency, o App Engine
tenta reutilizar uma instância existente. Se nenhuma instância conseguir
processar o pedido antes de max_pending_latency,
o App Engine cria uma nova instância.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-22 UTC."],[],[],null,[]]
