Teste de performance: o segredo está no planejamento

Teste de performance: o segredo está no planejamento

Texto: Fábio Correia/Software Test Consultant no CESAR

Em tempos de nuvem, escalabilidade e uso massivo da internet, não é incomum que uma simples publicação em uma rede social caia nas graças de usuários e, através de um fluxo massivo e quase sempre desordenado, derrube o servidor ou indisponibilize um serviço. Olhando um pouco para o trivial, uma consulta simples a um banco de dados mal estruturado pode ocasionar lentidão no uso da aplicação. Mesmo que não haja a concorrência nos acessos, é só a massa de dados ser minimamente densa e a escalabilidade do serviço ser zero para o problema ganhar vida.

Ambos cenários citados, e algumas centenas de outros não ponderados neste parágrafo, podem ocasionar a pior das situações: a perda da confiança do usuário pelo impacto da impossibilidade de uso, que geralmente é premissa básica em qualquer serviço.

Trazendo à luz o cenário de redes sociais do primeiro parágrafo, posso citar um exemplo que tem se tornado corriqueiro para exemplificar o caso: trata-se do “Reddit Hug of Death” (O abraço da morte do Reddit — tradução literal), que acontece quando um usuário do Reddit faz uma postagem recomendando um site, serviço ou publicando uma notícia específica e essa postagem acaba atingindo a front-page da rede social, gerando uma quantidade de acessos por parte dos usuários tão massiva que chega a derrubar o site/serviço referenciado (em grande parte das vezes).

Servidores, aplicações web, aplicações mobile, e todo e qualquer cenário do universo computacional que envolve uma troca ativa de bits e bytes através da nossa querida internet, se torna suscetível a uma sobrecarga, venha ela de um tsunami de usuários sedentos por algo, ou através de crackers mal intencionados buscando prejudicar um servidor através de um famigerado ataque de negação de serviço (cuidado: esse link de mapeamento dos DDoS é hipnótico!), e pensando nesses cenários eu sempre busco estruturar uma linha de pensamento preventiva, capaz de mensurar através de testes de performance, que abrangem testes de carga e estresse, o ponto de quebra dos sistemas testados.

Começando a fazer as contas

Nós, tão apegados a requisitos, sempre começamos as nossas jornadas em busca do estado de inexistência de bugs persistentes com perguntas. Uma vez que nos debruçamos nas possibilidades e cenários, isso faz ou deve fazer parte da nossa natureza investigativa. Como engenheiro de testes, eu sempre irei buscar insumos, recheando-os com sentimentos e expectativas, para conseguir entregar a melhor experiência aos usuários, validando o código de forma progressiva, esperando que o mesmo não esconda nenhuma surpresa. 

Mas o que fazer quando não temos números iniciais ou quando as perspectivas ainda são apenas um conjunto de dados e parâmetros ainda abstratos e pouco tangíveis? Bom, o primeiro passo é começar de onde você está, com o que você tem, fazendo o que der para fazer, e essa linha de iniciativa se aplica de forma bem eficaz para testes de performance.

Você já pensou como a capacidade de carga de uma ponte/viaduto é testada? © Copyright Calvin and Hobbes

Com alguns dos cenários ventilados, fazemos uma projeção além do mecânico, precisamos considerar comportamentos, especulando as possibilidades e mensurando o movimento de manada, assim como o cracker mal intencionado. É uma boa prática especular abertamente sobre o início da atividade em si, uma vez que, parametrizar, assim como estimar as situações de carga, acabam sendo a parte mais difícil da atividade. 

Considere o que pode acontecer caso os stakeholders forneçam uma estimativa pouco precisa, subestimando a natureza real das cargas, ou como e por quanto tempo haverá picos de acesso, considere também que por mais que tenhamos números supostamente exatos, para calcular o impacto deles precisaremos idealmente simulá-los, nos aproximar dos cenários assim como explodir as possibilidades com projeções algumas vezes bem afastadas da realidade, podendo assim descobrir pontos de quebra, para que depois de muito tempo exercitando os números e com ajuda de muita infraestrutura, talvez você não precise mais fazer.

Uma vez que a nossa conversa e grande parte da experiência se dá dentro de um universo normal corporativo, e que não começaremos tentando conter uma “Genki Dama” como o pessoal do Akamai fez segurando o GitHub, nós devemos nos ater a universos corporativos, de tráfego moderado, apostando as fichas e considerando as possibilidades de um grande volume em breves espaços de tempo e em determinadas situações, como um hot site de promoções, por exemplo, que será “atacado” em um período específico, ao mesmo tempo, não estaremos livres dos bugs funcionais no aspecto lógico como chamadas redundantes, cache desestruturado, e otras cositas más também precisam ser consideradas.

Já um cenário de fluxo intenso e constante, exige uma dedicação em nível industrial de validação, e geralmente a infraestrutura para tal já é mensurada de forma escalável tornando os testes de performance como coadjuvantes situacionais, uma vez que você não faz ideia sobre quando um vírus vai assolar o mundo obrigando tudo e todos a ficarem isolados em suas casas, exercitando cada milímetro da camada de infraestrutura de T.I do nosso pequeno e azul planeta.

Dentro de toda diversidade de cenários, uma coisa é fato: a performance do sistema e seus testes dependem de uma dedicação que se dá do começo ao fim (se é que tem um fim, né?!) do projeto, e deve envolver não só testadores pontualmente, mas desenvolvedores, responsáveis pela infraestrutura e também os stakeholders.

Quando me pedem para explicar de forma mais clara situações de estresse e carga de tiro curto, utilizo um vídeo bem didático para exemplificar, pois ainda não encontrei um jeito mais humano:

A porta é o servidor, os amarelinhos a tentativa de escalabilidade, o cara grandão chega tentando fazer o papel das regras de firewall mas desiste…

Configurando, isolando, medindo, estimando e evoluindo

Prepare-se para o fim! O segredo está no planejamento, e não tenha medo de ser um pouco apocalíptico, não nesse caso. O primeiro passo a ser considerado para os testes é a solução de infraestrutura escolhida: vamos de nuvem ou de uma estrutura de servidores anabolizados em algum data-center? Se formos pela primeira, ela será facilmente escalável, e o limite geralmente costuma ser o seu cartão de crédito e sua expertise tecnológica, porque não adianta nada você escalar ao infinito e além com uma arquitetura pouco eficiente e nada preparada para tratar grandes volumes, sejam de dados ou de acessos. Já a segunda, costuma ter um investimento inicial robusto e pouca ou nenhuma escalabilidade, podendo ser uma solução para uma demanda extremamente específica e linear.

O segundo passo se dá através da escolha do sistema, aplicações, arquitetura, quando muitas dessas dependem da aprovação dos stakeholders pelo impacto direto nos custos do projeto, já no que diz respeito à arquitetura, existem situações que os requisitos são levados ao pé da letra. Um amigo que hoje desenvolve em terras além-mar, sempre trouxe uma lógica brincante quando trabalhávamos na mesma equipe e eu questionava a performance da aplicação: “se funciona para 1, funciona para vários, se funcionou pra poucos certamente funcionará para muitos”, não acreditem nesse rapaz. 

Algumas cartas do Test Sphere que abordam situações relativas a testes de performance!

Há outras centenas de fatores que podem influenciar cada uma das escolhas, e é por isso que eu sugiro ser um pouco apocalíptico, pois devemos considerar a pouca visibilidade dos stakeholders e escolhas binárias por parte dos desenvolvedores na maioria das vezes.

Com todas as premissas atendidas e com o sistema em fase de testes, precisamos medir para conquistar. A base das métricas serão os números apontados pelos stakeholders, e no caso de não haver uma estimativa de uso, é também função dos testes de performance estruturar essa análise relativa ao uso e aos limites da solução, afinal, através do conhecimento de algo, nascem as estimativas.

O que medir? Basicamente, quantidades e a tolerância a elas, idealmente em ambientes isolados para que variáveis externas ao sistema não mascarem o bom ou o mau desempenho. As ferramentas mais modernas percorrem sempre caminhos bem lineares em relação às medições, e fornecem relatórios das execuções para uma análise posterior. As métricas mais habituais são:

  • Consumo dos recursos básicos do sistema — CPU e RAM;
  • Tempo de resposta para cada chamada (medido ponto-a-ponto);
  • Quantidade de requests atendidos por segundo (Throughput);
  • Tempo para o primeiro byte endereçado pelo servidor (TTFB);
  • Quantidade de conexões que falharam (claro que se houver falha!);
  • Quantidade de requisições que falharam (preciso repetir?!);

De quebra, anomalias como vazamentos de memória, problemas de sincronização, corrompimento de dados e uma variedade nada peculiar de comportamentos completamente nocivos ao produto, perceptíveis ou não para os usuários.

A pesada conclusão

Testes de performance e seus subgrupos atingiram um nível ainda maior de importância e relevância nesses tempos de exercícios elásticos em termos de tecnologia da informação dentro de uma pandemia, é extremamente benéfico que pratiquemos um pouco da saudável engenharia do caos, tão celebrada em serviços que estão habituados a trabalhar com picos de uso de forma mais rotineira que a maioria dos meros mortais, então, siga o seu instinto, redobre a validação das suas estimativas e considere que esse nicho de não-funcionais são parte essencial da mensuração de saúde da sua aplicação.

Procure entender as métricas coletadas de maneira científica, replique ambientes de produção, exploda os limites dos mesmos e nunca se dê por satisfeito. Quando você estiver exercitando tudo de maneira sistemática, quase na base da memória muscular, os gargalos dos sistemas testados conversarão com você.

P.S: Ferramentas, né?! Não falei sobre elas, e você entrou aqui procurando JMeter, Gatling ou Locust e eu me mantive na teoria, mas relaxa, um artigo com um pouco sobre cada uma delas vai para o forno em breve, prometo.

Quer saber mais sobre sobre como o CESAR pode te ajudar?

FALE COM UM CONSULTOR

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

div#stuning-header .dfd-stuning-header-bg-container {background-image: url(https://www.cesar.org.br/wp-content/uploads/2018/08/IMG_9090-1.jpg);background-size: initial;background-position: top center;background-attachment: initial;background-repeat: initial;}#stuning-header div.page-title-inner {min-height: 650px;}