Análise de Desempenho: Web API - Recursos técnicos

O seguinte artigo é um complemento do artigo "Análise de Desempenho: Web API", com o objetivo de explicar os scripts presentes no repositório do GitHub, artefatos usados para a coleta de dados e também análise dos mesmos. Também descrevo alguns passos na montagem do servidor.

[ Hits: 5.546 ]

Por: Saulo Gomes em 17/02/2016 | Blog: https://about.me/saulo.gomes


Geradores de Carga



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:
É 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:
Para mais informações sobre o Apahe Bench:
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:
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.

Página anterior    

Páginas do artigo
   1. Introdução
   2. Collectl
   3. WebAPI
   4. Geradores de Carga
Outros artigos deste autor

Análise de Desempenho: Web API

Leitura recomendada

Nagios 3 + NagiosQL no Ubuntu Server 12.04

AWS - VPN IPSEC com Libreswan

Tutorial de instalação e configuração do CACIC 3.1.15

Crimpagem de Conectores RJ-45

Configurando Placa Wireless Broadcom BCM43142 no SlackWare 14.2

  
Comentários

Nenhum comentário foi encontrado.


Contribuir com comentário