Articles

Teste de Carga de seu aplicativo com o Cerco

de julho de 2019

tag(s): rails_performance • calhas • programação
tempo de Leitura: 8 minutos
  • Dumping URLs exclusivos em um arquivo de texto
  • Visitar todas as páginas em um Cerco de teste
  • Recursos Adicionais

Última vez, pesquisei usando o Apache Benchmark para fazer o teste de desempenho em uma página que requer autenticação para acesso.

hoje, descobriremos como usar siege para visitar muitos URLs exclusivos em nossa página e obter benchmarks nesse processo. Em seguida, descobrirei o perfil de desempenho no Datadog e, com essas três ferramentas reunidas, devemos estar prontos para fazer algumas melhorias significativas em nosso aplicativo.

Esta série de posts é um resultado direto do The Complete Guide to Rails Performance de Nate Berkopec, com a ajuda de seus screencasts, bem como os aplicativos de trilhos de teste de carga de Steve Grossi com Apache Bench, Siege e JMeter. Armado com esses recursos,e de pé sobre os ombros de gigantes, vamos lá.

Descrição do cerco:

Siege é um utilitário de teste de carga http e benchmarking. Ele foi projetado para permitir que os desenvolvedores da web Medam seu código sob coação, para ver como ele resistirá à carga na internet. Siege suporta autenticação básica, cookies, HTTP, HTTPS e protocolos FTP. Ele permite que seu usuário atinja um servidor com um número configurável de clientes simulados. Esses clientes colocam o servidor “sob cerco.”

você pode obter cerco com brew install siege.

estou usando porque pode executar uma lista de URLs que você fornece. Imagine que seu aplicativo é uma loja e lista alguns milhares de produtos. Cada produto deve ter um URL exclusivo, algo como , ou talvez . Esse product-guid garante que você possa ter URLs exclusivos, mesmo que haja dois itens com o mesmo nome de produto.

sabendo o que está em seu banco de dados, você pode facilmente concat product-guid e product-name, colá-lo ao final de e criar uma lista de cem ou mil ou dez mil URLs de produtos exclusivos em seu aplicativo. Se você os salvou em um arquivo de texto e fez o Siege visitar cada uma dessas páginas o mais rápido possível… isso pode parecer uma espécie de bom teste de estresse, hein?

Dumping URLs exclusivos em um arquivo de texto #

Você provavelmente vai começar a trabalhar em um rails console sessão, para descobrir como acessar o esquema de URL apenas para a direita.

eu iniciei o console e digitar:

eu olhei no nosso dev base de dados para localizar uma conta com uma grande quantidade de dados; conta com o id 4887 é uma conta associada com o QA automação, e tem muitos dados.

campaign.to_param é como construímos URLs de nossas campanhas – apenas concats o guid com a string title, conforme fornecido pelo cliente, e chama .parameterize sobre ele. Para esse lote de campanhas, elas são geradas programaticamente por nosso conjunto de testes de controle de Qualidade automatizado.

quando terminar, você pode ver algo assim em all_campaign_urls.txt:

visitando todas essas páginas em um teste de cerco #

então, você pode siege --help e ver um sinalizador para passar em um arquivo:

já sei que precisaremos --file e --header, pois precisaremos falsificar sessões autenticadas enviando alguns cookies, O processo para o qual descrevi da última vez

o sinalizador --get parece útil:

obter, puxar para baixo cabeçalhos HTTP e exibir a transação. Ótimo para depuração de aplicativos.

então, vamos fazer login como nossa conta de QA. Como estou executando tudo isso localmente, posso encontrar o endereço de E-mail associado em nosso banco de dados. Não sei a senha, é claro, mas posso forçar uma redefinição de senha local, pegar o e-mail no Mailcatcher e configurá-lo para qualquer senha que eu quiser.

permite obter esses cabeçalhos.

podemos fazer uma solicitação de teste cURL com nossos cookies. Quando eu

$ curl -v http://localhost:3000/account/campaigns/dd4dfb48aa-dec-05-drive-by-test

eu espero ver a página de voltar, não um redirecionamento para /users/sign_in

o Que eu esperava, uma falha de autenticação para parecer:

cookies:

_ts_session_id: c86fd1fe38d7a6c56ce1ef5990045057fd827a2c5655094bcce3748d6ee6d3e4: ImRhMDY1YjdjYjMwNGNjNWUxNzFkNDhjOGQ0YzA0OTIwIg%3D%3D--98c228cb35af1a269ee894c22540b81848e2ed09

E nós estamos no negócio:

Observe os códigos de status de 200? Posso tail -f log/development.log e ver toda a atividade, indicando que os cookies enviados estão associados a um usuário autenticado.

a primeira coisa que noto é que parece que esses são tempos de carregamento de página extremamente longos.

estou tendo carga de Cerco Cerca de 162 URLs diferentes. Quando você executa siege com a configuração padrão, ele executa 20 usuários simultâneos. Isso parecia ser um pouco demais para o que meu localhost poderia lidar, então tentei diminuir o número de usuários simultâneos primeiro para dois usuários e depois para um.

para definir o número de usuários simultâneos, basta adicionar o sinalizador --concurrent=NUM. Eu ainda estava inundado com saída, então deixei cair usuários simultâneos para 1 e removi todas, exceto 20 páginas da lista de páginas para carregar. Eu dei-lhe um time bandeira de 60 segundos, bem: -t 60s

Quando tudo está dito e feito, você vai ver siege fazendo um monte de tempo GET de pedidos, assim como:

Eventualmente, tudo vai se resolver fora, e você terá um resumo do teste de carga:

Sim, OK, isso é legal, Josh, mas como diabos eu deveria fazer algo de útil com isso?

grande pergunta! É hora de ver onde nosso aplicativo está gastando a maior parte do Tempo, no mundo real. Poderíamos fazer mais benchmarking localmente, mas obviamente dados do mundo real, coletados de pessoas reais interagindo com seu aplicativo real em produção é a fonte de dados mais útil.

portanto, em breve estarei escrevendo, escrevi sobre como obter dados úteis de um aplicativo Rails no DataDog!

Deixe uma resposta

O seu endereço de email não será publicado.