Trabalho com a implementação de projetos WEB onde é comum a criação de novos ambientes dimensionados para atender 100, 200 ou 2000 usuários simultâneos. Toda uma infraestrutura é planejada, montada e depois testada para garantir a performance e estabilidade daquilo que foi contratado.

É claro que existe todo o tipo de cliente, o que pode comprar um servidor de US$ 1.000.000 e aquele que aproveita a máquina de café, mas todos eles desejam a mesma coisa, que aquilo que foi comprado atenda às suas expectativas e necessidades. Daí a necessidade de se rodar um teste de stress no ambiente para avaliar se todos os equipamentos e configurações foram feitas de forma adequada para garantir que não haverá nenhum problema antes da virada para produção.

Existem muitas empresas especializadas no Brasil na realização de testes de stress e apresentação dos dados coletados sintetizados na forma de relatórios, parte importante de todo o trabalho. Há uma série de metodologias que podem ser utilizadas para a confecção de relatórios de performance do ambiente que foi estressado, mas o mais importante são os dados coletados, são eles os responsáveis pelo fracasso ou sucesso do teste de stress.

Antes de iniciar um teste de stress, você deverá ter em mão as seguintes informações:

  • O que o usuário deseja testar: Performance, Estabilidade ou Funcionalidade ?
  • Se for performance e estabilidade, você fará um ataque DoS autorizado pelo cliente, onde o objetivo é ver o limite da infraestrutura montada para o seu cliente.
  • No caso da funcionalidade a coisa é bem diferente, o resultado final não tem nada a ver com performance, mas sim se tudo está funcionado de acordo com o que foi especificado.
  • Para os 3 pontos citados de testes você deverá ter em mãos: O desenho da arquitetura do ambiente que será testado, os componentes que fazem parte desta arquitetura (rede, servidores, aplicação e usuários), produtos e aplicações que serão testadas, a carga que o ambiente que foi montado deverá atender e o mais importante, a quantidade de usuários que acessarão este ambiente em curto, médio e longo prazo.

Com todas essas informações em mãos você passa para a segunda parte, o que deve ser coletado de informações para gerar o relatório final, vamos a algumas delas:

• Throughput

  • Bytes Received / Sec
  • Bytes Sent / Sec

• Connections

  • Maximum Connections
  • Current Connections

( estes dados deverão ser coletados de todos os equipamentos de redes, servidores e até mesmo de servidores aplicacionais, para saber se a sua rede está ok)

Os dados abaixo são referentes a coleta de dados para ambientes Windows.

• Memory

  • Committed Byted

Apresenta o consumo de memória virtual. Se este indicador fica acima da memória RAM, o sistema operacional faz ajustes no pagefile e pode impactar o tempo de resposta da solução.

  • Pages Output / Sec

Este indicador aponta quantas vezes páginas de memória virtual foram passadas para pagefiles para liberar memória RAM. O crescimento deste indicador aponta que existe uma demanda por memória maior do que a disponível. Valores próximos de zero apontam que memória RAM não é um problema – mesmo se o Committed Bytes está próximo de seus limites máximos.

  • Cache Bytes + Pool Nonpaged Bytes + Pool Paged Bytes + System Code Total Bytes + System Driver Total Bytes

O sistema operacional de 32 bits separa 2GB para compartilhar entre processos e o próprio SO independente da quantidade de Memória RAM disponível (configuração padrão). Desta forma, quando existe uma crescente demanda que supera os 2GB, o Load da máquina começa a aumentar – apontando enfileiramento de processos e degradação de performance. Desta forma, a soma destes indicadores deve ficar abaixo de 2GB.

• Paging File

  • %pagefile in use

Este contador indica quanto do pagefile está sendo ocupado. Quando o pagefile atinge 100%, ou seja o pagefile está completamente ocupado, as operações são paralisadas. Recomenda-se manter o % de pagefile em até 75%.

  • Processor
  • % Processor time

Este indicador aponta o consumo percentual do processador na linha do tempo.

Referência: http://support.microsoft.com/kb/2267427

Para servidores aplicacionais JAVA, temos os seguintes dados que deverão ser coletados:

  • TotalNumberOfThreads;
  • ExecuteThreadTotalCount;
  • Available Threads;
  • Machine CPU Usage;
  • JVM CPU Usage;
  • Used Physical Memory;
  • Used Java Heap;
  • Active Connections Current Count;
  • Waiting for Connection Current Count;
  • Open Session Current Count

Referência: http://www.neotys.com/documents/support/htmldoc2.2.x/ch09s04.html

Para servidores Unix e Linux, temos os seguintes dados que deverão ser coletados:

  • CPU Utilization
  • User Mode CPU Utilization
  • System Mode CPU Utilization
  • Outgoing Packets Rate
  • Outgoing Packets Error Rate
  • Incoming Packets Rate
  • Incoming Packets Error Rate
  • Disk Traffic
  • Collision Rate
  • Available Memory

Os indicadores acima assustam de início, mas isso representa cerca de 20% dos dados que você deverá coletar de um ambiente de médio ou grande porte, e para que o seu trabalho fique mais fácil, crie scripts que possam lhe auxiliar na coleta, eles devem ser rodados simultaneamente em todos os componentes analisados.

Mas o mais importante disso tudo é a análise final, é ela que dirá se o ambiente atenderá as necessidades do cliente ou não. Vejam que mesmo um teste bem sucedido pode levar ao fracasso e queda do ambiente no momento da entrada em produção, isso se os parâmetros escolhidos não reflitam a necessidade real do cliente, exemplo, o cliente pode ter subestimado a quantidade de usuários que iria acessar o ambiente. Isso já aconteceu comigo e foi feio, tive que reconfigurar uma série de parâmetros asap junto com os outros times, o cliente ficou feliz pois o resultado final superou as suas expectativas.

Vamos à parte divertida do teste de stress … afinal vocês não acharam que eu iria falar apenas de coisas técnicas sem contar o que dá para fazer de legal, né ?!

Pois bem, se o cliente autorizar um teste de performance e estabilidade querendo saber os limites da sua infraestrutura, prepare-se, você terá em suas mão um super ambiente, igual a milhares de outros que existem por aí, mas com um único diferencial: autorização formal para realização de um ataque DoS e a capacidade de analisar item a item, dando uma visão mais clara do que você está fazendo. 🙂

Um ataque DoS autorizado por um cliente tem um nome mais bonito, Test de Stress, vários aqui dirão que eu estou louco, mas um ataque DoS consiste na negação de um serviço, acessando-o ou requisitando-o tantas vezes que o servidor não consegue mais responder.

Há uma série de ferramentas de teste de stress que são verdadeiras máquinas de guerra, Apache Jmeter é uma das mais utilizadas e na minha opinião, uma das ferramentas que podem causar mais estragos. Tem uma da Microsoft que também é muito boa e é freeware (aleluia, aleluia), o WCAT (Web Capacity Analysis Tool), eu já presenciei a queda de um ambiente com 5 máquinas parrudas graças a este carinha.

Uma ferramenta que é paga e muito boa para stress teste é o yourkit, eu já a vi em funcionamento e em determinada ocasião me causou sérios problemas, a empresa que estava realizando os testes não tinha me avisado que os mesmos estavam rodando, foi um caos até eu ter matado com um kill -9 o agente e depois ter removido todos os acessos deles (ele ficaram bravos. :))

No seu dia a dia há várias formas de aprender como funcionam ataques hackers e o teste de stress é uma destas formas.