GAE As horas de instância front-end estão aumentando sem o aplicativo sendo usado (python-backend)

Question

Minhas horas de instância do Front-end do GAE continuam aumentando, mesmo que o aplicativo não esteja sendo usado e não há instâncias em execução (porque eu as encerro manualmente !!). Minha pergunta tem várias sub-perguntas, aqui estão elas:

1. Qual é o componente principal que afeta as horas de instância de front-end? Na minha implementação atual do sistema, estou fazendo uso extensivo dos seguintes recursos do google: Memcache, fila de tarefas e armazenamento de dados do NDB. Eu sei que o armazenamento de dados não tem muito a ver com as instâncias front-end (ou talvez eu esteja errado), mas o Memcache inflige horas de instância front-end? Até ontem, meu aplicativo estava funcionando perfeitamente e as horas de instância estavam sendo usadas (como seria de se esperar) quando a fila de tarefas estava sendo usada. O que me levou a acreditar que o principal fator era usar a fila de tarefas e enviar várias solicitações em um curto período de tempo. Mas esta manhã eu adicionei algum uso extra do memcache e ele começou a agir. Além disso, os recursos estáticos afetam as horas das instâncias?

2. Como otimizar a aplicação, quais são as principais coisas a considerar? Chamadas de API do Google, chamadas de URL em geral, novamente memcache?

Informações sobre aplicativos:

No meu arquivo app.yaml, aqui estão algumas das informações de configuração:

• default_expiration: 15m (eu tive 1h antes, mas mudei para testes)
• instance_class: F2 (Eu preciso tê-lo como F4 para algum processamento, mas mudei para F2 novamente para fins de teste)
• threadsafe: sim

Eu preciso ter um entendimento claro das horas da instância, as postagens que li aqui não são claras o suficiente! Se você tem uma compreensão profunda de como o Google calcula as horas de instância do front-end, por favor me avise! o que faz com que ele suba, como administrá-lo e todas essas coisas.

Algum contexto visual extra:

Resumo do processo

Como você pode ver nesta imagem, não há instâncias implantadas (nem instâncias sendo executadas), mas o faturamento está apenas aumentando e o gráfico de resumo está ficando louco !, veja todos esses picos!

Qualquer coisa seria muito apreciada!

    

Answer 1

Cálculo da hora da instância

Conforme escrito em Faturamento de instâncias , qualquer instância será exibida pelo menos 15 minutos, mesmo que receba um único pedido. Isso é em parte para evitar que muitos usuários finais experimentem a latência de gerar uma instância. Em vez disso, uma instância ficará inativa e pronta para receber solicitações imediatamente.

Quanto ao modo como as horas da instância são calculadas, isso é baseado no tempo real de operação. Se uma instância F1 estiver operacional por 2,5 horas, ela consumirá cerca de 2,5 horas de instância. O número de horas da instância é multiplicado pelo número da turma, conforme documentado na nota Importante , em Preços do App Engine . Portanto, uma instância F2 operando por 2 horas consumiria 4 horas de instância.

Otimização com simultaneidade e assincronia

Quando se trata de otimização, sua melhor aposta é delegar onde for apropriado e não perder tempo. Por exemplo, suponha que seu manipulador precise obter 3 entidades que contenham URLs do armazenamento de dados e depois buscar essas URLs para alguns dados JSON. Obter entidades do armazenamento de dados leva algum tempo. Se você estiver usando a versão síncrona das get chamadas, seu manipulador será basicamente bloqueado enquanto recebendo as entidades. Usar a versão assíncrona da get_async da mesma chamada da API permitirá que o manipulador continue com outras tarefas enquanto as entidades são recuperadas.

Da mesma forma, buscar URLs pode levar muito tempo. Fazer isso de forma síncrona pode congelar seu manipulador enquanto aguarda que eles retornem. A latência será ainda pior se essas solicitações nunca retornarem ou retornarem apenas com o tempo limite padrão. Embora a biblioteca urlfetch não tenha nenhuma busca assíncrona incorporada muitas bibliotecas de terceiros fazem ou se prestam bem à criação de threads em python. Em go , você pode buscar essas URLs em goroutines que são executadas simultaneamente. Isso permitirá que o manipulador não apenas continue com outras tarefas, mas também busque essas URLs em paralelo.

Identificando gargalos

Dependendo das necessidades da sua aplicação, pode haver muitas oportunidades para o design simultâneo. Isso pode reduzir bastante os tempos de resposta de suas instâncias, permitindo que elas processem mais solicitações ou diminuam o ritmo mais rapidamente, e as duas consomem menos horas de instância. Sugiro usar o Stackdriver Trace para estudar a duração de uma solicitação. Pode ser útil na identificação de gargalos. Com essas informações, você deve ter uma ideia de onde priorizar a otimização.