Teste de performance: o segredo está no planejamento

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.

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:

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.

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.