Skip links

Realizando Stress Test em Ecommerce

Saber quanto sua aplicação suporta em número de acessos simultâneos é sempre importante. Mas, na véspera de uma black friday, isso é imprescindível!

Há alguns anos, recebi uma tarefa (de última hora) que consistia em implementar e aplicar testes de stress em uma aplicação de ecommerce (na verdade, eram 2 ecommerces). Eu e mais um colega tínhamos cerca de 10 dias (pois estávamos próximo da black friday) para aprender uma nova linguagem, nova ferramenta, e implementar os fluxos básicos de um ecommerce, como busca, navegação e, posteriormente, criação de usuários e fechamento de pedidos. Mas daí começamos a nos deparar com termos como think time, ruptura, ramp up, dentre outros. Bom, mas o que significa tudo isso e como faremos para entregar e executar esses testes dentro do tempo?

Um pouco de explicação sobre o cenário

A plataforma que deveríamos utilizar para realizar os testes era a Load Impact. Ela permitia desenvolvermos scripts em Lua* e rodarmos cargas que simulavam acessos de usuários vindos de qualquer lugar do mundo (origem que poderia ser configurável).

*A nova versão da Load Impact permite utilizar JavaScript e Go ao invés de Lua.

Devido ao fato de desenvolvermos os scripts em Lua, nosso grupo de discussão no Skype logo ganhou o carinhoso nome de ‘Apollo 11’ (imagem destaque do post).

Ao testar um ecommerce, diversos cenários podem ser avaliados, desde busca por memory leaks em uma aplicação após cargas altas durante tempo prolongado, se o sistema continua respondendo bem depois de estar sob grande pressão, como também identificar o ponto de ruptura, ou seja, qual é a carga máxima que o sistema comporta antes de parar de responder.

Este último era o cenário que tínhamos que trabalhar; tínhamos que identificar qual era o número máximo de usuários simultâneos que a aplicação conseguiria aguentar. E, para isso, precisávamos simular o comportamento de usuários reais para que obtivéssemos um valor mais próximo da realidade.

Pausa para definições

Antes de prosseguir, algumas definições bem rápidas sobre termos que serão utilizados:

Ruptura: Ponto em que o sistema para de responder, ou seja, a carga de acessos foi tão grande que o sistema não suportou. Esse ponto é importante para identificarmos se o sistema irá suportar a carga esperada de acessos de uma black friday ou se precisaremos adicionar mais infraestrutura para isso.

Ramp up: Determina como será o aumento do número de usuários na aplicação. Para determinarmos se o ecommerce suporta acessos de 100k usuários, por exemplo, não começamos testando direto em 100k. Ao invés disso, começamos com um número baixo de usuários e vamos aumentando gradativamente. Também não é recomendado um aumento linear, pois fica difícil identificar qual é o ponto de ruptura. Se o sistema cair, teremos certeza que não aguenta o total de usuários do nosso teste, mas não sabemos exatamente qual é o ponto de ruptura. Para isso, aumentamos o número de usuários em 10k de maneira linear, por exemplo, mantemos por 30 segundos, depois aumentamos novamente em 10k, e assim por diante. Dessa forma, temos um ramp up melhor e mais fácil de conseguirmos realmente identificar o ponto de ruptura.

Think Time: Tempo de ‘pensamento’ do usuário, ou seja, o tempo médio que ele leva para clicar na página. A partir desse tempo médio que calculamos através de dados disponibilizados pelo Google Analytics (GA), podemos alterar alguns parâmetros no nosso script para, randomicamente, termos uma média de tempo entre cada click similar ao ecommerce real.

Continuando…

Através do GA, conseguimos alguns dados que foram importantes para parametrizar nossos scripts. Dessa forma, tínhamos uma ideia de como os usuários se comportavam no site, e em páginas específicas (home, busca, categorias, detalhes do produto, carrinho e checkout). Também obtivemos um percentual de quantos usuários estavam em cada parte do site para que nossos testes pudessem ser ainda mais próximos ao mundo real.

Esses testes utilizavam apenas chamadas GET e POST, pois não havia como emular um browser na Load Impact. Dessa forma, foi necessário identificar as chamadas que cada página fazia, e passá-las aos nossos scripts (inclusive chamadas ajax). Apesar de termos implementado também a possibilidade de invocar conteúdos estáticos, acabamos não utilizando devido ao ecommerce fazer uso de uma CDN, ou seja, chamadas aos conteúdos estáticos não chegavam até a aplicação, uma vez que a CDN disponibilizava-os aos usuários.

Após scripts estarem prontos e parâmetros configurados, era hora de colocar a aplicação à prova. Como os acessos durante o dia podiam impactar nos testes, eles sempre foram realizados durante a madrugada, onde o acesso de usuários é bastante reduzido. Dessa forma, em alguns momentos, chegamos a passar o dia e a noite desenvolvendo e testando os scripts, a madrugada realizando os testes e, na sequência, até o período do início da manhã gerando relatórios que seriam enviados à diretoria sobre os resultados obtidos e sugestões de melhorias em apache, weblogic, número de máquinas, memória… [ainda bem que a CLT coíbe essas situações hoje em dia].

A partir dessas sugestões e outros detalhes identificados pela equipe de infraestrutura, novos testes eram executados em noites subsequentes, modificando alguns parâmetros utilizados, atualizando nossos ramp ups, aumentando o número de usuários simultâneos e assim por diante, até que chegássemos, no mínimo, ao número esperado de clientes para a Black Friday daquele ano.

Concluindo…

A ideia era passar um pouco da experiência que tive nessa área. Apesar do pouco tempo disponível, a execução acabou sendo um sucesso. No entanto, não atuei mais nessa área desde então, pois foi montado um time especificamente para isso e acabaram ficando responsáveis por evoluir os scripts desenvolvidos. Maiores informações sobre o Load Impact podem ser encontrados diretamente na plataforma deles. Inclusive, eles disponibilizam diversas outras opções de testes além de apenas testes de carga. Abaixo segue um exemplo simples de execução, exibindo o número de usuários, requests e falhas por segundo de uma única URL especificada.

Teste de execução realizado na Load Impact, exibindo um ramp up linear, e o número de requests e falhas por segundo. Em um teste mais complexo, poderíamos identificar uma queda no número de request ao subir o número de usuários, evidenciando o ponto em que o site começa a sofrer degradação, normalmente acompanhado de um aumento significativo no número de falhas.


Leave a comment

Name*

Website

Comment