Fale sobre o JMeter? Provavelmente, se você está no assunto, já leu tudo sobre esta ferramenta para teste de estresse. Mas tenho algo para te surpreender. Durante três anos no controle de qualidade, percebi que o JMeter é muito versátil e pode ser usado para uma variedade de propósitos. Por exemplo, para:
- procure um bug indescritível com a queda do site para alguns usuários;
- aquecimento rápido do cache em milhares de páginas de produtos;
- testando o back-end de um aplicativo móvel;
- criando 2000 registros com dados do usuário no banco de dados do aplicativo em pouco tempo.
Se você estiver interessado, bem-vindo ao gato. Ficou volumoso, então vou dividir o artigo em duas partes.
Isenção de responsabilidade: por razões óbvias, não insiro capturas de tela de projetos reais no artigo (nem extrao todas as informações importantes). As ilustrações são fornecidas apenas para fins educacionais e de pesquisa.
Aplicação JMeter clássica
JMeter - miniaplicativo Java com GUI. Para o teste, ele inicia sem uma interface gráfica. E para escrever scripts de teste, ele tem um painel no qual você pode fazer qualquer coisa.
É assim que o processo de criação do script se parece (aqui, mesmo a palavra "escrita" não se encaixa)Um plano de teste comum é criado, no qual o grupo de threads se lança com os principais elementos do teste: controladores de processo e solicitações (HTTP, FTP, etc.).
Além disso, existem elementos adicionais para definir parâmetros. Por exemplo, Padrões de solicitação HTTP permitem especificar o servidor principal, os cabeçalhos e ativar / desativar o download de ativos adicionais (imagens, estilos, fontes, etc.). É fácil descobrir isso. E você pode executar imediatamente um teste nessa interface e ver os resultados.
O JMeter pode registrar esses casos de teste. Ele é executado como um proxy na máquina local e, se você configurar um navegador (ou aplicativo), direciona o tráfego por esse proxy, o JMeter registrará todas as solicitações e respostas. E a partir desse conjunto, você pode inventar um script de teste que repetirá as ações do usuário e executá-lo onde e quando quiser:
O principal problema é a pilha da própria memória Java. Ele repousa no teto e pode cair com 50 linhas de testes simultâneos, mesmo em máquinas de ponta.
Se a máquina não tiver energia suficiente para um teste de carga total, entre em contato com uma organização de terceiros. Eles implantaram uma infraestrutura que é um conjunto de servidores. Eles têm o mesmo JMeter. Por uma taxa, esses caras executam seu script em qualquer carga. Nós solicitamos esses serviços na Octoperf e Blazemeter.
Isso é futebol, baby: como pegamos um bug com uma falha parcial no servidor
Estamos envolvidos no desenvolvimento da web há 18 anos (saúde - agora você pode fumar, casar e assistir John Wick). Houve muitos clientes em sua vida, mas os maiores apareceram recentemente. Por exemplo, criamos um site no
Sitecore para um dos clubes de futebol da Premier League inglesa com o paradigma SPW (site de uma página: todas as páginas abrem sem recarregar a própria página do navegador). Sob o capô está o painel de administração para gerenciar uma página de jogo ao vivo. Esta é uma transmissão textual on-line do jogo: os principais eventos (gols, exclusões, cobranças de falta) são carregados automaticamente no sistema Opta, e fotos, comentários e republicações de fãs do Twitter e Instagram são publicados por pessoas ao vivo - gerentes de conteúdo de clubes de futebol.
Não sem orgulho, observo: após o lançamento, a mídia britânica publicou artigos sob os títulos "Finalmente, a hegemonia dos antigos sites dos clubes de futebol acabou". Naquela época, a maioria dos clubes já tinha sites. Mas eles pareciam ter sido desenvolvidos no início dos anos 2000 e não mudaram desde então - com o design e o UX correspondentes.
Antes do lançamento, realizamos um teste de carga total e garantimos que tudo funcione como deveria. A estrutura do servidor ficou assim:
- a solicitação do cliente vai para o servidor de balanceamento de carga →
- O servidor de balanceamento de carga verifica o status de oito servidores de CD →
- O servidor de balanceamento de carga envia uma solicitação ao servidor de CD menos carregado →
- O servidor de CD responde ao cliente.
Um ano após o lançamento, durante um grande fluxo de usuários para o site, o cliente ligou e disse que o site estava inoperante:
- Nosso site não funciona! Não funciona! Apenas uma tela branca e uma inscrição do navegador que o site está fora do ar! - o cliente diz.
Estamos em pânico ao abrir o site, e com ele está tudo bem:
"Ainda funciona", respondemos.
O cliente abre o site pelo telefone e pelo computador e ... está tudo bem também!
Desculpe mesmo. Aparentemente, os usuários têm problemas.
Como essas mensagens não aparecem do zero, realizamos um estudo: lançamos um utilitário para monitorar o status dos servidores com Densidade de Servidor e analisamos o que acontece com eles durante um fluxo de usuários no site:
Existe uma carga, mas todos os servidores de CD têm a mesma aparência e atéLogo a história se repetiu - alguns usuários relataram um site completamente quebrado. Não houve nenhum tipo de erro ou página não encontrada - o servidor simplesmente não respondeu à solicitação. Foi possível pegar a situação com a ajuda do JMeter.
O objetivo era simples - carregar todos os oito servidores e ver o que acontece. Um teste de estresse foi realizado quando o amanhecer acontecia em Chelyabinsk e em Londres era uma noite profunda. Usamos várias máquinas no modo sem interface (permite executar muito mais threads ao mesmo tempo). O script abriu infinitamente a página inicial, e esse foi o nosso principal erro.
Baixamos os mesmos ativos que já foram armazenados em cache centenas de vezes. Portanto, a carga saiu insignificante. Então surgiu a idéia: no site - uma carruagem e um pequeno carrinho de páginas com notícias para determinadas datas. Se você avançar algumas variáveis e substituí-las no URL, sempre obteremos uma página aleatória (por exemplo - ... url / news / 2016/08/23 /? Page = 4).
De repente, percebemos que a Densidade do Servidor possui alguma “suavização” interna nos gráficos de carga do servidor nos períodos anteriores. Se em cinco minutos a carga no servidor atingir 100%, cair para 0% e após 20 a 30 segundos aumentar para 90%, ele mostrará o valor médio desse período - cerca de 80-90%. Portanto, não vimos uma falha real do servidor.
Depois de examinar os logs em detalhes durante os testes de estresse, descobrimos que um dos servidores de CD foi reinicializado com 100% de carga e não contou a ninguém sobre ele (ele é um introvertido).
O balanceador de carga examinou apenas a utilização da CPU de todos os servidores. Ele viu que um deles estava carregado com 20% e o restante com 90%, e enviou o usuário ao primeiro. E ele estava na reinicialização e deu uma tela branca. Além disso, o servidor de distribuição expôs o usuário a um cookie e o vinculou firmemente ao servidor ocioso. Portanto, mesmo após a atualização, o site não estava disponível. Os 7 dos 8 usuários restantes ao mesmo tempo desfrutaram a vida e disseram que tudo funciona.
Conclusão:
descobrimos que o JMeter pode ser usado para testes de estresse e ao mesmo tempo analisar o status dos servidores durante o teste com outras ferramentas. Conseguimos “capturar” o problema com a queda do site entre alguns usuários e resolvê-lo, corrigindo a lógica de distribuição de carga e adicionando controle de estado.
Na próxima parte, mostrarei como, com a ajuda do JMeter, configuramos o processo de armazenamento em cache para páginas de produtos, testamos a operação de um aplicativo móvel sem o próprio aplicativo e criamos 2000 usuários no sistema sem acesso ao banco de dados.