Para o experimento eu utilizei dois geradores de carga, para ter duas visões do mesmo teste e também conhecer os pontos de cada abordagem.

JMETER

O primeiro foi o JMeter, software da Fundação Apache, possui boa fama como gerador de carga já que não testa somente requisições HTTP, mas também de outros protocolos de rede, como por FTP, LDAP, SMTP e conexões TCP de modo genérico, além de outros recursos.

O script com o plano de testes está disponível no GitHub:

• https://github.com/saulobr88/Artigo_CapacityPlanning_2015/blob/master/Load%20Test%20HTTP.jmx

É um arquivo XML que o JMeter usa para saber o fluxo do experimento, a configuração desse script é para executar uma sequência progressiva de requisições HTTP para a WebAPI configurada no servidor de testes. A progressão segue de 1, 10, 20, 30... 150 com intervalos de 5 segundos entre cada grupo de requisições.

Para uma explicação sobre como utilizar o JMeter, eu recomendo esse vídeo do Canal do YouTube JMeter Tutorials:

APACHE BENCH

O Apache Bench, também da fundação Apache, vem no pacote apache2-utils, foi criado com o intuito de testar a performance de servidores Web, independente de qual servidor web está sendo utilizado. Pode ser chamado pelo comando ab:

# which ab | xargs dpkg -S
apache2-utils: /usr/bin/ab

Um exemplo do ab em execução:

ab -l -r -n 100 -c 5 -k http://<Endereço IP da Máquina que está executando o Apache>/

A opção -n indica o número de requisições, enquanto a opção -c indica a ocorrência de conexões simultâneas (conexões concorrentes).

As opções -l, -r e -k são para adaptar a requisição ao tipo de página que testaremos, direto da man page:

• -k     Enable the HTTP KeepAlive feature, i.e., perform multiple requests within one HTTP session. Default is no KeepAlive.
• -l     Do not report errors if the length of the responses is not constant. This can be usefull for dynamic pages.
• -r     Don't exit on socket receive errors.

Como queremos testar, e isso inclui chegar ao estado de stress do servidor, temos que aceitar erros durante a execução dos testes, principalmente quando estivermos testando com um grande volume de requisições concorrentes.

Esse comando deve ser executado em algum outro computador, não é para executar no servidor, na verdade se for executado no servidor não saberemos como está o desempenho referente à comunicação da rede, já que a comunicação seria de localhost para localhost.

Para testar como está o tempo de resposta do nosso servidor usando a WebAPI, podemos executar:

ab -l -r -n 1 -c 1 -k http://<IPv4>/RestAPI/RestDBClient.php

Com o comando acima testaremos quanto tempo a API consegue nos entregar a lista com os nomes da tabela 'actor' para 1 cliente (uma conexão apenas). Eu coloquei os scripts PHP dentro do diretório /var/www/html/RestAPI/.

No repositório do GitHub há um script que automatiza a execução dos testes de forma progressiva:

• https://github.com/saulobr88/Artigo_CapacityPlanning_2015/blob/master/ab.sh

Para mais informações sobre o Apahe Bench:

• Usando ApacheBench para testes: Apache/mod_rails e Nginx/mongrel | leonardofaria.net
• ab - Apache HTTP server benchmarking tool - Apache HTTP Server Version 2.2

Desse modo nosso ambiente está pronto para executarmos os testes.

Considerações Finais

Como informado no artigo inicial, o ambiente (Hardware) é para simular uma instância EC2 oferecida de forma gratuita pela Amazon Web Services, logo possui Processamento, Memória e Armazenamento reduzido.

Para executar o(s) teste(s) o procedimento é:

(1) Executar o collectl no servidor e em seguida (2) executar a rotina de teste do JMeter ou do Apache Bench em um outro computador, de preferência.

Muitas informações teóricas e também sobre o porquê do método podem ser encontradas no artigo inicial:

• Análise de Desempenho: Web API [Artigo]

Gostaria de agradecer a toda equipe do VOL e também a comunidade pelo grande e ótimo trabalho feito até hoje, o que mostra que sistemas GNU/Linux continuarão sendo a vanguarda para serviços de infraestrutura por muito tempo ainda.