Tenha um aplicativo Java com dimensionamento automático no ambiente padrão do Google App Engine. No momento, o dimensionamento está configurado assim:

<instance-class>F2</instance-class>

<automatic-scaling>
    <min-idle-instances>1</min-idle-instances>

    <!-- ‘automatic’ is the default value. -->
    <max-idle-instances>2</max-idle-instances>

    <!-- ‘automatic’ is the default value. -->
    <min-pending-latency>2000ms</min-pending-latency>

    <max-pending-latency>8000ms</max-pending-latency>
    <max-concurrent-requests>60</max-concurrent-requests>
</automatic-scaling>

Apenas comecei a tentar oF2 instância, estava usandoF1 instâncias anteriores. Não importa como eu configure meu dimensionamento automático, parece que a instância recém-criada (criada quando a carga aumenta) começa a receber todas as solicitações recebidas, enquanto a instância residente fica com uma carga muito leve.

Por que é isso? Obviamente, não consigo monitorar o tráfego (e para qual instância ele vai) em tempo real, mas toda vez que olho a história parece a mesma. Incluí algumas capturas de tela de exemplo abaixo.

e no caso a seguir, três instâncias (essa foi uma configuração ligeiramente diferente da acima) ficam livres, mas o balanceador de carga do GAE escolhe enviar todas as solicitações para a instância com a maior latência!

Mais um exemplo: este é o log de solicitações para oresidente instância iniciada às 10:15:45 hoje:

e o log de solicitações para odinâmico instância iniciada 10 segundos depois:

Como você pode ver, a instância dinâmica está lidando com todas as solicitações (1889 até agora) enquanto o residente fica essencialmente ocioso (7 no mesmo período). Isso ainda seria bom se não fosse o fato de que as instâncias residentes parecem serdestruído e criado de novo na mesma época em que novas instâncias dinâmicas estão sendo criadas. Isso significa que, por um minuto ou mais, todos os pedidos têm um tempo de resposta de 10 a 20 segundos.

Alguém pode me explicar como configurar?

Aqui está o que eu quero:

Uma instância inativa deve poder lidar com a carga na maioria das vezes (por enquanto).Quando mais solicitações forem recebidas, crie uma instância adicional.Quando estiver pronto, comece a desviar o tráfego para ele.

Estou tentando executar um site de carga razoável com um orçamento apertado, por isso é importante que eu tente ficar o mais próximo possível da cota gratuita.

Atualização 1

Como as duas respostas falam sobre a solicitação de aquecimento com destaque, pensei em listar detalhes sobre isso aqui. Estou usando umServletContextListener para lidar com a inicialização. Faz o seguinte (os horários são reunidos usando o Guava'sStopwatch classe e são para o código que eu escrevi / estou invocando explicitamente):

Registrar entidades Objectify (1.449 s)Freemarker init 229 msFirebase init 228.2 ms

Fora isso, tenho o filtro Shiro, o filtro Objectify e o filtro Jersey (em Jersey, estou evitando a verificação do caminho de classe (acho)) registrando explicitamente as classes em vez de fornecer um pacote para verificação) configurado no meuweb.xml. Não usar nenhuma injeção de dependência para evitar a verificação do caminho de classe.

o/_ah/warmup A solicitação demorou 7,8s (a partir da qual os horários acima foram obtidos). Porém, as solicitações sendo atendidas por uma instância dinâmica iniciada recentemente, cujo aquecimento já foi concluído, estão levando mais de 10 segundos para serem concluídas, apesar do fato de essas mesmas chamadas levarem de 200 a 700ms dois minutos depois. Então, o que mais está acontecendo em segundo plano, além das coisas que estou explicitamente fazendo no meuStartupListener?

Aqui estáparte 1 do log e aqui estáparte 2 do log.