Testando a performance de aplicações utilizando o siege e docker

Para testar a velocidade/disponibilidade/performance de um site, utilizando o siege. A primeira coisa que vamos fazer é clonar o repositório

Siga os seguintes passos:

git clone git@github.com:samhk222/siege-blog.git && cd siege-blog && docker-compose build && docker-compose u

Depois de executado o comando, você já tem uma imagem docker rodando … para procurá-la basta digitar o comando

Você verá uma imagem que se chama siege-local …. para rodar os testes em um servidor, execute o comando abaixo

docker run --rm -t siege-local -b -r 50 -c 100 https://www.yahoo.com.br

Entendendo os parâmetros utilizados

Parâmetro	Parâmetros
-c 100	O parâmetro -c 100 indica que, para esse teste de stress, utilizaremos 100 usuários concorrentes. É como se o siege criasse 100 usuários para você. Esse número só é limitado pelos seus recursos da máquina.
-r 50	O parâmetro -r 50 indica o número de repetições, com conjunto com o parâmetro -c acima. Ou seja, serão 100 usuários, repetindo o teste 50x. Não iremos abordar aqui, mas o siege aceita um parâmetro que seria a lista de urls, e nesse caso ele repetiria todos os ítens da lista 50x. Seriam 100 x 50 = 5000 hits no servidor.

Entendendo o retorno

Retorno	Explicação
Transaction	É a quantidade de vezes que vamos bater no servidor. Seria a multiplicação dos parâmetros -c e -r
Elapsed Time	Tempo total. Vai desde o momento que chamamos o siege, até a ultima request.
Data transfered	Total de dados transferidos. Inclui header + body da request.
Response time	Tempo médio de resposta da requisição.
Transaction rate	Transaction rate é a media de números de transações que o servidor conseguiu lidar por segundo… ou seja, é o número de transações divididas pelo tempo (Elapsed time)
Throughput	É a média de dados por segundo que foi transferida pelo servidor
Concurrency	A média de número de requisições simultâneas. Quanto maior esse número, melhor seu server está
Successful transactions	Qualquer response code <= 400 entra como successful transactions
Failed transactions	Qualquer response code >= 400 entra como failed transactions
Longest transaction	Transação que demorou mais para executar. Seja por conta da banco de dados, ou apache/nginx

Então, quais são os resultados ideais ? Parece meio obvio falar isso, mas depende da sua situação. Porque o resultado em um server compartilhado difere de um server rodando em uma instância EC2 dedicada….

Na prática o que EU gosto de fazer, é rodar com vários cenários de teste até derrubar o server e ver quantos usuários ele aguenta. Gosto também de sempre deixar o transaction rate acima de 100, e o concurrency entre 85 e 90. Dessa forma eu tenho uma boa fluidez em todo os sites que já subi.

Testando sites no docker

Uma pegadinha que eu vi rodando o site dentro do docker foi o seguinte … para rodar o siege em um site que foi ‘subido’ junto com o container do siege, precisamos fazer o seguinte

docker run –rm -t siege-local -b -r 50 -c 100 http://172.17.0.1

Sendo que http://172.17.0.1 é nosso ip interno do docker ….