Realizando um teste de estresse em aplicativos da Web?

No passado, usei o Microsoft Web Application Stress Tool e o Pylot para testar aplicativos da web. Eu escrevi uma página inicial simples, um script de login e uma explicação passo a passo do site (em um site de comércio eletrônico, adicionando alguns itens a um carrinho e check-out).

Atingir fortemente a página inicial com um punhado de desenvolvedores quase sempre localizava um grande problema. Mais problemas de escalabilidade surgiriam no segundo estágio e ainda mais - após o lançamento.

O URL das ferramentas que usei foram o Microsoft Homer (também conhecido como Microsoft Web Application Stress Tool ) e o Pylot .

Os relatórios gerados por essas ferramentas nunca fizeram muito sentido para mim, e eu passava muitas horas tentando descobrir que tipo de carregamento simultâneo o site poderia suportar. Sempre valia a pena, porque sempre surgiam os bugs e gargalos mais estúpidos (por exemplo, configurações incorretas do servidor da web).

O que você fez, quais ferramentas você usou e que sucesso teve com sua abordagem? A parte que é mais interessante para mim é apresentar algum tipo de fórmula significativa para calcular o número de usuários simultâneos que um aplicativo pode suportar a partir dos números relatados pelo aplicativo de teste de estresse.

Aqui está outra votação para o JMeter .

O JMeter é uma ferramenta de teste de carga de código aberto, escrita em Java. É capaz de testar vários tipos diferentes de servidores (por exemplo, web, serviços web, banco de dados, praticamente qualquer coisa que use solicitações basicamente).

No entanto, ele tem uma curva de aprendizado acentuada quando você começa a fazer testes complicados, mas vale a pena. Você pode começar a trabalhar muito rapidamente e, dependendo do tipo de teste de estresse que deseja fazer, isso pode ser bom.

Prós:

• Ferramenta de código-fonte aberto / gratuito do projeto Apache (ajuda com a adesão)
• Fácil de começar e fácil de usar depois de entender os conceitos principais. (Ou seja, como criar uma solicitação, como criar uma asserção, como trabalhar com variáveis ​​etc).
• Muito escalável. Eu executei testes com 11 máquinas gerando carga no servidor na ordem de quase um milhão de hits / hora. Era muito mais fácil de configurar do que eu esperava.
• Possui uma comunidade ativa e bons recursos para ajudá-lo a começar a trabalhar. Leia os tutoriais primeiro e brinque com ele por um tempo.

Contras:

• A interface do usuário está escrita no Swing. (ugh!)
• O JMeter funciona analisando o texto de resposta retornado pelo servidor. Portanto, se você deseja validar qualquer tipo de comportamento javascript, está sem sorte.
• A curva de aprendizado é íngreme para não programadores. Se você está familiarizado com expressões regulares, já está à frente do jogo.
• Há um grande número de ( insira palavrões ) idiotas no fórum de suporte, fazendo perguntas estúpidas que poderiam ser facilmente resolvidas se eles dessem à documentação um olhar superficial. ('Como uso o JMeter para testar a minha GUI do Windows' aparece com bastante frequência).
• Relatar 'fora da caixa' deixa muito a desejar, principalmente para testes maiores. No teste que mencionei acima, acabei tendo que escrever um aplicativo de console rápido para fazer algumas das conversões 'xml-logfile' para 'html'. Isso foi há alguns anos, portanto, é provável que isso não seja mais necessário.

Eu usei o Grinder . É de código aberto, muito fácil de usar e muito configurável. É baseado em Java e usa Jython para os scripts. Nós o executamos em um aplicativo Web .NET, portanto, não pense que é uma ferramenta apenas para Java (por natureza, qualquer ferramenta de estresse na Web não deve estar ligada à plataforma que usa).

Fizemos algumas coisas legais com ele ... éramos um aplicativo de telecomunicações baseado na Web, então um uso legal que eu configurei foi imitar a discagem de um número através do nosso aplicativo da Web e depois usamos uma ferramenta de resposta automática que tínhamos (que era basicamente um tutorial aplicativo da Microsoft para conectar-se ao servidor RTC LCS ... que é o que o Microsoft Office Communicator se conecta a uma rede local ... e modificado para atender apenas as chamadas automaticamente). Isso nos permitiu usar isso em vez de uma ferramenta de telefonia cara chamada The Hammer (ou algo assim).

De qualquer forma, também usamos a ferramenta para ver como nosso aplicativo se sustentava sob alta carga e foi muito eficaz para encontrar gargalos. A ferramenta incorporou relatórios para mostrar quanto tempo as solicitações estão demorando, mas nunca as usamos. Os logs também podem armazenar todas as respostas e outros enfeites, ou log personalizado.

Eu recomendo muito essa ferramenta, muito útil pelo preço ... mas espero fazer alguma configuração personalizada com ela (ela possui um proxy embutido para gravar um script, mas pode precisar de personalização para capturar algo como sessões ... eu sei Eu tive que personalizá-lo para utilizar uma sessão única por thread).

Um pouco tarde para esta festa. Concordo que o Pylot é a melhor ferramenta de código aberto disponível no mercado. É simples de usar e é trabalhado ativamente por um cara legal ( Corey Goldberg ). Como fundador do OpenQA , também estou feliz que o Pylot agora esteja listado em nossa home page e use parte de nossa infraestrutura (principalmente os fóruns).

No entanto, recentemente também decidi que todo o conceito de teste de carga era defeituoso: emular o tráfego HTTP, com aplicativos tão complexos quanto eles se tornaram, é um problema. Por isso, criei a ferramenta comercial BrowserMob. É um serviço de teste de carga externo que usa o Selenium para controlar navegadores da Web reais ao reproduzir o carregamento.

A abordagem, obviamente, exige uma tonelada mais hardware do que as técnicas normais de teste de carga, mas hardware é realmente muito barato quando você está usando a computação em nuvem. E um bom efeito colateral disso é que o script é muito mais fácil do que o teste de carga normal. Você não precisa fazer nenhuma correspondência de regex avançada (como o JMeter exige) para extrair cookies, estado da sessão do .NET, parâmetros de solicitação do Ajax, etc. Como você usa navegadores reais, eles apenas fazem o que devem fazer.

Desculpe por exibir um produto comercial descaradamente, mas espero que o conceito seja interessante para algumas pessoas e, pelo menos, faça com que elas pensem em novas maneiras de lidar com o teste de carga quando você tiver acesso a um monte de hardware extra!

Eu usei o JMeter . Além de testar o servidor da web, você também pode testar o back-end do banco de dados, os serviços de mensagens e os servidores de email.

ab , cerco , tsung , httperf , Trample , Pylot, analisador de logs de solicitações , perftools

Para uso simples, eu prefiro ab (benchmark apache) e cerco, mais tarde é necessário, pois ab não suporta cookies e criaria sessões intermináveis ​​a partir do site dinâmico.

ambos são simples de começar:

ab -c n -t 30 url

siege -b -c n -t 30s url

o cerco pode ser executado com mais URLs.

a última versão do cerco é ativada detalhadamente no siegerc, o que é irritante. você só pode desativá-lo editando esse arquivo ( /usr/local/etc/siegerc).

Para um serviço baseado na Web, confira loader.io .

Resumo:

O loader.io é um serviço de teste de carga gratuito que permite que você teste seus aplicativos-web / APIs com milhares de conexões simultâneas.

Eles também têm uma API .

Como essa questão ainda está em aberto, é melhor eu avaliar.

A boa notícia é que, nos últimos cinco anos, as ferramentas de código aberto realmente amadureceram e decolaram no espaço, a má notícia é que existem muitas delas por aí.

Aqui estão os meus pensamentos: -

Jmeter vs Grinder

O Jmeter é direcionado a partir de uma especificação de estilo XML, construída por meio de uma GUI.

O Grinder usa scripts Jython dentro de uma estrutura Java com vários threads, mais orientada para programadores.

Ambas as ferramentas lidam com HTTP e HTTPS e têm um gravador proxy para você começar. Ambas as ferramentas usam o modelo do controlador para conduzir vários agentes de teste, de modo que a escalabilidade não é um problema (acesso à nuvem).

Qual é melhor:-

Uma decisão difícil, pois a curva de aprendizado é íngreme com as duas ferramentas, à medida que você entra nos requisitos de script mais complicados para reescrita de URL, correlação, fornecimento de dados exclusivos por Usuário Virtual e simulação de usuários iniciantes ou recorrentes (manipulando os Cabeçalhos HTTP).

Dito isto, eu começaria com o Jmeter, já que esta ferramenta tem muitos seguidores e existem muitos exemplos e tutoriais na Web para usar essa ferramenta. Se e quando você chegar a um 'obstáculo', isso é algo que você não pode 'facilmente' fazer com a Jmeter, dê uma olhada no Grinder. A boa notícia é que essas duas ferramentas têm o mesmo requisito Java e uma solução de 'combinação e combinação' não está fora de questão.

Algo novo a acrescentar - navegadores sem cabeça executando várias instâncias do Selenium WebDriver.

Essa é uma abordagem relativamente nova, pois depende da disponibilidade de recursos que agora podem ser provisionados a partir da nuvem. Com essa abordagem, um script Selenium (WebDriver) é obtido e executado em um navegador sem cabeçalho (por exemplo, WebDriver = New HtmlUnitDriver ()) em vários threads.

Por experiência, cerca de 25 instâncias de 'navegadores sem cabeça' podem ser executadas na Instância Pequena do Amazon M1.

O que isto significa é que todos os problemas de correlação e reescrita de URL desaparecem à medida que você adapta novamente seus scripts de teste funcional para se tornarem scripts de teste de desempenho.

A escalabilidade é comprometida, pois mais VMs serão necessárias para impulsionar a carga, em comparação com um driver HTTP, como o Grinder ou o Jmeter. Dito isso, se você deseja impulsionar 500 usuários virtuais, então, com 20 pequenas instâncias da Amazon (6 centavos por hora cada) a um custo de apenas US $ 1,20 por hora, você terá uma carga muito próxima da experiência real do usuário.

Além disso, existe uma incrível estrutura de gafanhotos distribuída e escalável em python puro de código aberto que usa greenlets . É ótimo para simular uma enorme quantidade de usuários simultâneos.

Recentemente, começamos a usar o Gatling para testes de carga. Eu recomendo experimentar esta ferramenta para teste de carga. Nós tínhamos usado SOASTA e JMETER no passado. Nosso principal motivo para considerar Gatling é o seguinte:

• Gravador para gravar o cenário
• Usando Akka e Netty, que oferece melhor desempenho, compare com o modelo Jmeter Threading
• DSL Scala, que é de fácil manutenção, comparado com o Jmeter XML
• Fácil de escrever os testes, não se assuste se for scala.
• Comunicando

Deixe-me dar um exemplo simples para escrever o código usando o Código Gatling:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

No entanto, você pode torná-lo o mais complicado possível. Um dos recursos que se destacam para Gatling é o relato, que é muito detalhado.

Aqui estão alguns links:
Gatling
Gatling Tutorial

Recentemente, dei uma palestra sobre isso, você pode seguir a conversa aqui:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

Essa é uma pergunta antiga, mas acho que soluções mais recentes merecem menção. CheckItem LoadImpact: http://www.loadimpact.com .

Eu tentei o WebLoad , é uma ferramenta bem legal. Ele vem com um script de teste IDE, que permite gravar a ação do usuário em um site. Ele também desenha um gráfico ao executar o teste de estresse no servidor da web. Experimente, eu recomendo.

Tentando tudo o que foi mencionado aqui, achei o curl-loader o melhor para meus propósitos. interface muito fácil, monitoramento em tempo real, estatísticas úteis, a partir das quais construo gráficos de desempenho. Todos os recursos do libcurl estão incluídos.

O Blaze Meter possui uma extensão chrome para gravar sessões e exportá-las para o JMeter (atualmente requer login). Você também tem a opção de pagar a eles para executá-lo no cluster de servidores JMeter (o preço parece muito melhor do que o LoadImpact, que acabei de parar de usar):

• Extensão BlazeMeter Chrome
• Entrada do blog sobre ele

Não tenho nenhuma associação com eles, apenas gosto da aparência do serviço deles, embora ainda não tenha usado a versão paga.

Você fez essa pergunta há quase um ano e não sei se ainda está procurando outra maneira de comparar o seu site. No entanto, como essa pergunta ainda não está marcada como resolvida, gostaria de sugerir o serviço da web gratuito LoadImpact (btw. Não afiliado). Acabei de receber este link via twitter e gostaria de compartilhar esse achado. Eles criam uma boa visão geral razoável e, por alguns dólares a mais, você obtém o "modo de impacto total". Provavelmente isso parece estranho, mas boa sorte ao pressionar e frear seu serviço :)

Encontrei o IBM Page Detailer também uma ferramenta interessante para trabalhar.

Eu usei o openSTA .

Isso permite que uma sessão com um site seja gravada e reproduzida por uma linguagem de script relativamente simples.

Você pode facilmente testar serviços da Web e escrever seus próprios scripts.

Ele permite que você monte scripts em um teste da maneira que desejar e configure o número de iterações, o número de usuários em cada iteração, o tempo de aceleração para introduzir cada novo usuário e o atraso entre cada iteração. Os testes também podem ser agendados no futuro.

É de código aberto e gratuito.

Produz vários relatórios que podem ser salvos em uma planilha. Em seguida, usamos uma tabela dinâmica para analisar e representar graficamente os resultados com facilidade.

Usamos a ferramenta Microsoft mencionada - Microsoft Web Application Stress Tool. É a ferramenta mais fácil que já usei. É limitado de várias maneiras, incluindo apenas a possibilidade de atingir a porta 80 em testes criados manualmente. Mas, sua facilidade de uso significa que ele realmente é usado.

Complementamos a carga dessa ferramenta com outras ferramentas, incluindo OpenSTA e aranhas de verificação de link.

O JMeter parece bom em minha avaliação inicial, espero incluí-lo em nossa integração contínua daqui para frente. Mas, o JMeter é complexo e não é trivial.

Eu sugiro abrir outra pergunta sobre a interpretação dos resultados da ferramenta de estresse com EM.

Visual Studio Test Edition 2010 (2008 também). Esta é uma ferramenta realmente fácil e poderosa para criar testes de carga / Web.

O bônus com essa ferramenta ao usar nos servidores Windows é que você obtém acesso integrado a todas as estatísticas de servidor perfmon em seu relatório. Muito útil.

O outro bônus é que, com o projeto do Visual Studio, você pode integrar uma "Sessão de desempenho" que apresentará o perfil da execução do código do seu site.

Se você estiver exibindo páginas da Web de um servidor Windows, esta é a melhor ferramenta disponível.

No entanto, é necessária uma licença separada e cara para usar várias máquinas para carregar o aplicativo de teste.

Desenvolvemos um processo que trata a medição de carga e desempenho como uma preocupação de primeira classe - como você diz, deixá-lo no final do projeto tende a levar à decepção ...

Portanto, durante o desenvolvimento, incluímos testes multiusuário muito básicos (usando selênio), que verifica loucuras básicas como gerenciamento de sessões interrompidas, problemas óbvios de simultaneidade e problemas óbvios de contenção de recursos. Projetos não triviais incluem isso no processo de integração contínua, para que recebamos feedback muito regular.

Para projetos que não têm requisitos extremos de desempenho, incluímos testes básicos de desempenho em nossos testes; geralmente, criamos scripts dos testes usando o BadBoy e os importamos para o JMeter, substituindo os detalhes de login e outras coisas específicas do segmento. Em seguida, aumentamos esses níveis até o nível em que o servidor está lidando com 100 solicitações por segundo; se o tempo de resposta for inferior a 1 segundo, geralmente é suficiente. Lançamos e seguimos em frente com nossas vidas.

Para projetos com requisitos de desempenho extremos, ainda usamos o BadBoy e o JMeter, mas dedicamos bastante energia para entender os gargalos dos servidores em nossa plataforma de teste (geralmente servidores da Web e de banco de dados). Há uma boa ferramenta para analisar logs de eventos da Microsoft que ajuda muito nisso. Normalmente, encontramos gargalos inesperados, que otimizamos se possível; que nos fornece um aplicativo o mais rápido possível em "1 servidor web, 1 servidor de banco de dados". Em seguida, geralmente implantamos em nossa infraestrutura de destino e usamos um dos serviços "Jmeter na nuvem" para executar novamente os testes em escala.

Novamente, os relatórios PAL ajudam a analisar o que aconteceu durante os testes - você geralmente vê gargalos muito diferentes nos ambientes de produção.

A chave é garantir que você não apenas execute seus testes de estresse, mas também colete as informações necessárias para entender o desempenho do seu aplicativo.

Existem muitas boas ferramentas mencionadas aqui. Gostaria de saber se as ferramentas são uma resposta à pergunta: "Como você estressa o teste de um aplicativo da web?" As ferramentas não fornecem realmente um método para enfatizar um aplicativo da Web. Aqui está o que eu sei:

O teste de estresse mostra como um aplicativo Web falha ao fornecer respostas a uma crescente população de usuários. O teste de estresse mostra como o aplicativo Web funciona enquanto falha. A maioria dos aplicativos da Web hoje - especialmente os aplicativos Social / Móvel da Web - são integrações de serviços. Por exemplo, quando o Facebook teve uma interrupção em maio de 2011, não foi possível acessar o aplicativo Web da Pepsi.com. O aplicativo não falhou completamente, apenas uma grande parte de sua função normal ficou indisponível para os usuários.

O teste de desempenho mostra a capacidade de um aplicativo Web manter tempos de resposta independentes de quantos usuários estão usando o aplicativo simultaneamente. Por exemplo, um aplicativo que lida com 10 transações por segundo com 10 usuários simultâneos deve lidar com 20 transações por segundo com 20 usuários. Se o aplicativo manipular menos de 20 transações por segundo, os tempos de resposta aumentarão e o aplicativo não poderá alcançar escalabilidade linear.

Além disso, no exemplo acima, a contagem de transações por segundo deve ser apenas de operações bem-sucedidas de um caso de uso de teste / fluxo de trabalho. As falhas geralmente ocorrem em intervalos de tempo mais curtos e tornam a medição do TPS excessivamente otimista. As falhas são importantes para um teste de estresse e desempenho, pois também geram carga no aplicativo.

Eu escrevi a metodologia PushToTest no Guia do Usuário do TestMaker em http://www.pushtotest.com/pushtotest-testmaker-6-methodology . O TestMaker possui dois tipos: versão Open Source (GPL) Community e TestMaker Enterprise (comercial com ótimo suporte profissional).

-Frank

Dê uma olhada no LoadBooster ( https://www.loadbooster.com ). Utiliza PhantomJS / CasperJs, navegador sem script, para testar sites. O Phantomjs irá analisar e renderizar todas as páginas, executar o script do lado do cliente. A abordagem do navegador sem cabeça é mais fácil de criar cenários de teste para oferecer suporte a aplicativos pesados ​​da Web 2.0 AJAX complexos - navegação do navegador, clique do mouse e pressionamentos de teclas no navegador ou aguarde até que um elemento exista no DOM. O LoadBooster também suporta scripts HTML selênio.

Disclaimer: Eu trabalho para o LoadBooster.

Experimente o ZebraTester que é muito mais fácil de usar que o jMeter. Eu uso o jMeter há muito tempo, mas o tempo total de configuração para um teste de carga sempre foi um problema. Embora o ZebraTester não seja de código aberto, o tempo que economizei nos últimos seis meses compensa isso. Eles também têm um portal SaaS que pode ser usado para executar rapidamente testes usando seus geradores de carga.

Mais uma observação: para nosso aplicativo da Web, descobri que tínhamos grandes problemas de desempenho devido à contenção entre threads sobre bloqueios ... então a moral era pensar muito cuidadosamente no esquema de bloqueio. Acabamos tendo threads de trabalho para limitar muitas solicitações usando um manipulador http assíncrono; caso contrário, o aplicativo ficaria sobrecarregado, travaria e queimaria. Isso significava que um grande estoque poderia se acumular, mas pelo menos o site continuaria funcionando.

Dê uma olhada no TestComplete .

Eu segundo a sugestão do opensta. Gostaria de acrescentar que ele permite que você faça coisas para monitorar o servidor que você está testando usando SMTP. Nós controlamos a carga do processador, a memória usada, os bytes enviados etc. A única desvantagem é que, se você encontrar algo útil e quiser fazer uma correção, isso depende de várias bibliotecas de código-fonte aberto que não são mais mantidas, para obter uma compilação A versão da fonte é mais complicada do que na maioria dos OSS.

Eu brinquei com o JMeter. Um acha que não pôde testar foi o ASP.NET Webforms. O viewstate quebrou meus testes. Não sei muito bem o porquê, mas existem algumas ferramentas por aí que não lidam bem com o estado de exibição. Meu projeto atual é o ASP.NET MVC e o JMeter funciona bem com ele.

Tive bons resultados com o FunkLoad :

• fácil script de interação do usuário
• relatórios são claros
• pode monitorar a carga do servidor

Correndo o risco de ser acusado de autopromoção desavergonhada, gostaria de salientar que, na minha busca por uma ferramenta de teste de carga livre, visitei este artigo: http://www.devcurry.com/2010/07/10-free- tools-to-loadstress-test-your.html

Ou não consegui a taxa de transferência que queria ou não obtive a flexibilidade que queria. E eu queria agregar facilmente os resultados de vários hosts de geração de teste de carga na análise pós-teste.

Tentei todas as ferramentas da lista e, para minha frustração, descobri que nenhuma delas fazia exatamente o que eu queria poder fazer. Então eu construí um e estou compartilhando.

Aqui está: http://sourceforge.net/projects/loadmonger

PS: Não há comentários maliciosos sobre o nome de pessoas familiarizadas com gírias urbanas. Eu não era, mas sou um pouco mais mundana agora.

Também voto no jMeter e quero adicionar algumas citações à resposta @PeterBernier.

A principal pergunta que carrega as respostas dos testes é quantos usuários simultâneos meu aplicativo da web suporta? Para obter uma resposta adequada, o teste de carga deve representar o uso real do aplicativo, o mais próximo possível .

Lembre-se: o jMeter possui muitos controladores lógicos , elementos de configuração , pré-processadores , ouvintes , ... que podem ajudá-lo nisso.

Você pode imitar a situação do mundo real com o jMeter, por exemplo, você pode:

1. Configurar jMeter para atuar como navegador real configurando ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Configurar jMeter para gerar solicitações de usuários (por definir number of users per second, ramp-up time, scheduling, ...)
3. Configure muitos clientes com o jMeter, para fazer um teste de carga distribuída.
4. Processe a resposta para descobrir se o servidor está respondendo corretamente durante o teste. (Por exemplo, assertresposta para encontrar um texto)

Por favor considere:

• É fácil iniciar um teste real de aplicativo da web com o jMeter em minutos. O jMeter possui uma ferramenta muito fácil que registra seu cenário de teste (conhecido como HTTP(S) Test Script Recorder).
• O jMeter tem muitos plugins em http://jmeter-plugins.org .
• A interface do usuário do jMeter é baseada em swing e fez boas alterações no jMeter 3.2. Por outro lado, considere que a JMeter GUI deve ser usada apenas para teste e depuração. Não é uma boa prática usá-lo no modo GUI para teste real. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . Configure e teste seu cenário e execute-o no modo não gui.
• Existem muitos relatórios mostrando ferramentas no jMeter (conhecido como listeners), mas não devem estar ativados durante o teste. Você deve executar seu teste e gerar relatórios ( .jtlarquivos). Então você deve usar essas ferramentas para analisar o resultado. Consulte https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats ou https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm .

O https://www.blazemeter.com/jmeter possui informações muito boas e práticas para ajudá-lo a configurar seu ambiente de teste.