Esta página fornece práticas recomendadas para testar a carga do seu serviço do Cloud Run de modo a determinar se é dimensionado com êxito durante a utilização em produção e para encontrar eventuais gargalos que impeçam o dimensionamento.
Testes a executar antes dos testes de carga
Identifique e resolva problemas de concorrência num ambiente de desenvolvimento ou de teste pequeno antes de avançar para os testes de carga. Meça a simultaneidade do contentor antes de fazer um teste de carga e certifique-se de que o serviço do Cloud Run é iniciado de forma fiável.
Concentre os testes de contentores em pequenas contagens incrementais em execuções dimensionadas manualmente. Pode aproximar o dimensionamento manual no Cloud Run definindo o número de instâncias máximas para o valor que quer dimensionar.
Se tiver criado a imagem de contentor ou alterado recentemente a imagem de contentor, teste-a de forma independente antes de realizar um teste de carga.
Também deve verificar outros tipos de problemas de desempenho, como latência excessiva e utilização da CPU, antes de executar um teste de carga em grande escala.
Use max instances de forma adequada
O Cloud Run aplica um número máximo de instâncias para limitar o dimensionamento de um serviço. O número máximo predefinido de instâncias é 100. Se espera que o teste de carga exceda este valor predefinido, certifique-se de que trabalha com a equipa de conta da Google e define um novo máximo. Se ainda não tiver uma relação com uma equipa de contas, contacte as vendas do Google Cloud.
O número máximo de instâncias que pode selecionar depende dos seus limites de CPU e limites de memória, bem como da região para a qual está a fazer a implementação.
Estes limites são geridos por um limite de quota e podem ser aumentados através de um pedido de aumento do limite de quota.
Teste de carregamento na região europe-west1
A Google Cloud região europe-west1 oferece um limite de quota elevado, pelo que a Google recomenda o teste de carga em europe-west1.
Coordene com a equipa da sua conta e envie um registo de apoio técnico com detalhes da hora e da escala do teste se esperar aproximar-se dos limites de quota.
Teste um perfil de inicialização de serviço e utilização da CPU adequado
Num cenário ideal, implementa uma versão de teste do seu serviço no Cloud Run e testa o carregamento diretamente. No entanto, em alguns casos, pode não conseguir implementar uma versão de teste do seu serviço. Por exemplo, o seu serviço do Cloud Run pode fazer parte de um ecossistema complexo difícil de replicar num ambiente de teste.
Nestes casos, pode aproximar o desempenho do seu serviço simulando-o com um serviço mais simples que tenha uma utilização da CPU comparável e tempos de inicialização comparáveis.
O tempo de inicialização é particularmente importante para o dimensionamento rápido. Tenha em atenção que
testar com algo demasiado simples também é problemático. Por exemplo, evite testar com um serviço hello world simples que devolve pedidos recebidos sem processamento.
Use um ambiente de teste para gerar cargas
Pode gerar cargas de teste que causem um pico controlado no tráfego através de um ambiente de teste, como o JMeter. Pode usar o número de grupos de threads do JMeter e o atraso entre pedidos no teste do JMeter para aumentar a carga.
Também pode enviar pedidos HTTP simples ou gravar uma sessão do navegador com o JMeter. O Cloud Run permite-lhe testar o seu serviço sem acesso à Internet através da autenticação de programador. Isto permite o acesso a partir de um ambiente de teste, como o JMeter, em execução numa máquina virtual do Compute Engine associada a uma nuvem privada virtual associada ao projeto.
Não gere carga a partir de ferramentas em que não é possível controlar a taxa e a simultaneidade. O Pub/Sub é uma má escolha de ferramenta para gerar carga porque não pode controlar a taxa de tráfego e o número de clientes. Se não souber a taxa e a simultaneidade, não sabe o que está a testar.
Use a análise detalhada de registos através de registos exportados
Precisa de uma análise dos eventos ao segundo para compreender a resposta do seu serviço do Cloud Run a picos de tráfego rápidos. É necessária uma análise de registos para o fazer, porque o nível de detalhe dos dados de monitorização não é suficientemente detalhado. A análise de registos também lhe permite investigar os motivos dos pedidos com latência elevada.
Quando escreve registos, pode obter um melhor desempenho de registo escrevendo diretamente
em stdout, em vez de usar uma biblioteca de cliente do Cloud Logging.
Para configurar uma exportação de registos antes de iniciar o teste, crie um destinatário de registos com o destino BigQuery e um filtro de inclusão, como:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Evite inícios a frio espúrios
Para minimizar os inícios a frio experimentados pelos utilizadores, defina o número mínimo de instâncias para, pelo menos, 1.
Certifique-se de que o seu serviço é expandido linearmente
Repita o teste com cargas diferentes para se certificar de que o seu serviço do Cloud Run é dimensionado linearmente com a carga e não atinge um gargalo limitativo com uma carga inferior à esperada na produção.
Analise e visualize os resultados no Colab
Use os gráficos de monitorização de resumo para compreender os resultados de forma geral e complementar a análise detalhada de registos através de registos exportados.
Os gráficos de monitorização podem ajudar a descobrir:
- Com que rapidez, ao segundo mais próximo, são criadas e inicializadas novas instâncias?
- Como são distribuídos os pedidos uniformemente por diferentes instâncias?
- Com que rapidez é possível reduzir a latência em diferentes percentis para um valor de estado estável?
Pode usar a interface do utilizador da consola do BigQuery para analisar o esquema de registos exportado e pré-visualizar os resultados. Google Cloud Execute as consultas e represente graficamente os resultados através do Colab, que tem uma integração pronta com o BigQuery, o Pandas e o Matplotlab. O Colab também se integra facilmente com ferramentas de visualização de dados avançadas, como o Seaborn.
Encontre restrições
Os testes de carga podem ajudar a descobrir a existência de código ineficiente e gargalos de escalabilidade. O código ineficiente gera custos mais elevados, uma vez que tem de processar mais tráfego, mas não impede necessariamente o dimensionamento. Por exemplo, uma dependência de uma tradução de base de dados com bloqueio ao nível da tabela pode ser um gargalo que impede o serviço do Cloud Run de ser dimensionado, porque só é possível executar uma transação de cada vez.
Verifique o desempenho tal como é experienciado pelo cliente
Pode consultar os registos capturados pelo JMeter, onde os registos incluem latências medidas no cliente. No entanto, uma vez que as ferramentas de teste de servidor, como o JMeter, não são iguais a um navegador ou a um cliente móvel, também pode querer executar um teste com uma framework baseada no navegador, como o Selenium Webdriver, ou uma framework de teste de cliente móvel. Tenha cuidado com as latências máximas excessivas devido à inicialização da ligação TLS, que podem distorcer os resultados com valores atípicos.
Resumo das práticas recomendadas
Faça um teste de carga para determinar se a migração para o Cloud Run é a escolha certa e se o seu serviço pode ser dimensionado para o tráfego máximo esperado. Execute o teste com um arnês, como o JMeter. Exporte os registos para o BigQuery para uma análise detalhada.