Apache Bench - Guia rápido

O teste de desempenho provou ser crucial para o sucesso de um negócio. Um site de baixo desempenho não apenas enfrenta perdas financeiras, mas também pode levar a repercussões legais às vezes.

Ninguém quer tolerar um site de desempenho lento e não confiável em interações online importantes, como compras, realização de testes online, pagamento de contas, etc. Com a Internet tão amplamente disponível, a variedade de alternativas é imensa. É mais fácil perder clientela do que ganhá-la, e o desempenho é um fator chave para mudar o jogo.

Necessidade de uma ferramenta de teste de carga

Se pudermos entender qual é a necessidade de uma ferramenta de teste de carga, isso nos dará o motivo e a motivação para usá-la. Alguns sites de negócios famosos sofreram sérios períodos de inatividade ao receberem um grande número de visitantes. Os sites de comércio eletrônico investem pesadamente em campanhas publicitárias, mas não em testes de carga. Portanto, eles falham em garantir o desempenho ideal do sistema, quando esse marketing traz tráfego.

Outro exemplo familiar de ignorar o teste de carga é o “erro ao estabelecer conexão” em sites WordPress. Portanto, é uma boa ideia fazer o teste de carga de um site ou aplicativo antes de sua implantação na produção. É bom estabelecer rapidamente um cenário de melhor caso para um projeto antes de executar testes mais detalhados no futuro.

O que é o Apache Bench?

Apache Bench (ab) é uma ferramenta da organização Apache para benchmarking de um servidor da web Hypertext Transfer Protocol (HTTP). Embora seja projetado para medir o desempenho do servidor da web Apache, também pode ser usado para testar qualquer outro servidor da web que seja igualmente bom. Com essa ferramenta, você pode saber rapidamente quantas solicitações por segundo seu servidor da web é capaz de atender.

Recursos do Apache Bench

Vamos ver os recursos e limitações importantes do Apache Bench. Os recursos e limitações estão listados abaixo -

Por ser um software de código aberto, está disponível gratuitamente.
É um programa de computador de linha de comando simples.
É uma ferramenta independente de plataforma. Isso significa que pode ser invocado no Linux / Unix ou no servidor Windows da mesma forma.
Ele pode realizar testes de carga e desempenho apenas para o servidor web - HTTP ou HTTPS.
Não é extensível.

O Apache Bench usa apenas um encadeamento do sistema operacional, independentemente do nível de simultaneidade (especificado pelo sinalizador -c). Portanto, ao comparar servidores de alta capacidade, uma única instância do Apache Bench pode ser um gargalo. Para saturar completamente o URL de destino, é melhor usar instâncias adicionais do Apache Bench em paralelo, se o seu servidor tiver vários núcleos de processador.

Precaução

Você precisa estar ciente de que não há nenhuma diretiva no Apache Bench para aumentar a simultaneidade em intervalos específicos durante a execução de testes. Portanto, a execução de testes de carga usando ab é equivalente a um ataque de negação de serviço (DOS). É recomendável que você informe e obtenha permissão prévia de seu provedor de serviços VPS se for fazer testes de carga pesada por um longo período de tempo. Eles darão a você um intervalo de tempo apropriado ou mudarão seu nó para a tarefa de teste de carga.

Em segundo lugar, se você estiver testando o site de uma terceira pessoa continuamente e por um longo tempo apenas para aprender o Apache Bench de seu VPS (que se torna o nó de teste), há uma possibilidade remota de que seu IP público VPS possa ser bloqueado pelo site da terceira permanentemente. Nesse caso, você não poderá se conectar a esse site com o mesmo IP. Mas se você realmente deseja se conectar ao site no futuro, a única solução será conversar com o administrador do sistema do site de destino ou criar uma nova instância do servidor com um IP diferente com a ajuda do seu provedor de serviços VPS.

Tendo avisado você, deixe-me assegurar-lhe que todos os testes neste tutorial são seguros o suficiente e fora do que os administradores de sistema geralmente chamam de práticas de "abuso do sistema".

Neste capítulo, iremos guiá-lo como configurar seu ambiente para Apache Bench em seu VPS.

Requisitos do sistema

Memory - 128 MB
Disk Space - Sem requisitos mínimos
Operating System - Sem requisitos mínimos

Instalando o Apache Bench

O Apache Bench é um aplicativo independente e não depende da instalação do servidor da web Apache. A seguir está um processo de duas etapas para instalar o Apache Bench.

Step 1 - Atualizar banco de dados de pacotes.

# apt-get update

Observe que o símbolo # antes de um comando de terminal significa que o usuário root está emitindo esse comando.

Step 2 - Instale o pacote apache2 utils para obter acesso ao Apache Bench.

# apt-get install apache2-utils

O Apache Bench está instalado agora. Se você deseja testar um aplicativo web hospedado no mesmo VPS, basta instalar o servidor web Apache apenas -

# apt-get install apache2

Sendo um utilitário Apache, o Apache Bench é instalado automaticamente na instalação do servidor da web Apache.

Verificando a instalação do Apache Bench

Vamos agora ver como verificar a instalação do Apache Bench. O código a seguir ajudará a verificar a instalação -

# ab -V

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Quando você vê a saída do terminal acima, significa que você instalou com sucesso o Apache Bench.

Criando um Usuário Sudo Privilegiado

Do ponto de vista da segurança, é considerada uma boa prática para o administrador do sistema criar um usuário sudo em vez de trabalhar como root. Criaremos um usuário de teste, denominado test, para a finalidade -

# useradd -m -d /home/test -g sudo test

Vamos definir a senha para o novo usuário -

# passwd test

O sistema solicitará uma nova senha para o teste do usuário. Você pode inserir uma senha simples, pois estamos apenas testando, e não implantando no servidor de produção. Normalmente, o comando sudo solicitará que você forneça a senha de usuário sudo; é recomendado não usar senhas complicadas, pois o processo se torna complicado.

Output

Enter new UNIX password:
Retype new UNIX password:   
passwd: password updated successfully

Testando o site Apache.org

Nesta seção, testaremos o site Apache.org. Vamos primeiro mudar para o teste de usuário sudo -

# su test

Para começar, vamos testar o site da organização Apache, https://www.apache.org/. Vamos primeiro executar o comando e, em seguida, entender a saída -

$ ab -n 100 -c 10 https://www.apache.org/

Aqui -né o número de solicitações a serem executadas para a sessão de benchmarking. O padrão é apenas executar uma única solicitação, o que geralmente leva a resultados de benchmarking não representativos.

E -cé a simultaneidade e denota o número de várias solicitações a serem executadas ao mesmo tempo. O padrão é uma solicitação por vez.

Portanto, neste teste, o Apache Bench fará 100 solicitações com simultaneidade 10 para o servidor da organização Apache.

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        58769 bytes

Concurrency Level:      10
Time taken for tests:   1.004 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5911100 bytes
HTML transferred:       5876900 bytes
Requests per second:    99.56 [#/sec] (mean)
Time per request:       100.444 [ms] (mean)
Time per request:       10.044 [ms] (mean, across all concurrent requests)
Transfer rate:          5747.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   46  30.9     41     263
Processing:    37   40  21.7     38     255
Waiting:       12   15  21.7     13     230
Total:         77   86  37.5     79     301

Percentage of the requests served within a certain time (ms)
  50%     79
  66%     79
  75%     80
  80%     80
  90%     82
  95%     84
  98%    296
  99%    301
 100%    301 (longest request)

Depois de executar nosso primeiro teste, será fácil reconhecer o padrão de uso para este comando, que é o seguinte -

# ab [options .....]  URL

Onde,

ab - Comando Apache Bench
options - sinalizadores para uma tarefa específica que desejamos realizar
URL - URL do caminho que queremos testar

Compreendendo os valores de saída

Precisamos entender as diferentes métricas para entender os vários valores de saída retornados por ab. Aqui vai a lista -

Server Software - É o nome do servidor web retornado no cabeçalho HTTP do primeiro retorno bem-sucedido.
Server Hostname - É o DNS ou endereço IP fornecido na linha de comando.
Server Port- É a porta à qual ab está se conectando. Se nenhuma porta for fornecida na linha de comando, o padrão será 80 para http e 443 para https.
SSL/TLS Protocol- Este é o parâmetro de protocolo negociado entre o cliente e o servidor. Isso só será impresso se SSL for usado.
Document Path - Este é o URI de solicitação analisado a partir da string da linha de comando.
Document Length- É o tamanho em bytes do primeiro documento retornado com sucesso. Se o comprimento do documento mudar durante o teste, a resposta será considerada um erro.
Concurrency Level - Este é o número de clientes simultâneos (equivalente a navegadores da web) usados durante o teste.
Time Taken for Tests - Este é o tempo decorrido desde o momento em que a primeira conexão de soquete é criada até o momento em que a última resposta é recebida.
Complete Requests - O número de respostas bem-sucedidas recebidas.
Failed Requests- O número de solicitações consideradas com falha. Se o número for maior que zero, outra linha será impressa mostrando o número de solicitações que falharam devido à conexão, leitura, comprimento de conteúdo incorreto ou exceções.
Total Transferred- O número total de bytes recebidos do servidor. Esse número é essencialmente o número de bytes enviados pela rede.
HTML Transferred- O número total de bytes do documento recebidos do servidor. Este número exclui bytes recebidos em cabeçalhos HTTP
Requests per second- Este é o número de solicitações por segundo. Este valor é o resultado da divisão do número de solicitações pelo tempo total gasto.
Time per request- O tempo médio gasto por solicitação. O primeiro valor é calculado com a fórmula simultaneidade * timetaken * 1000 / done, enquanto o segundo valor é calculado com a fórmula timetaken * 1000 / done
Transfer rate - A taxa de transferência calculada pela fórmula totalread / 1024 / timetaken.

Análise rápida da saída do teste de carga

Tendo aprendido sobre os títulos dos valores de saída do comando ab, vamos tentar analisar e entender os valores de saída para nosso teste inicial -

A organização Apache está usando seu próprio software de servidor web - Apache (versão 2.4.7)
O servidor está escutando na Porta 443 por causa do https. Se fosse http, teria sido 80 (padrão).
O total de dados transferidos é de 58.769 bytes para 100 solicitações.
Teste concluído em 1.004 segundos. Não há solicitações com falha.
Solicitações por segundo - 99,56. Este é considerado um número muito bom.
Tempo por solicitação - 100,444 ms (para 10 solicitações simultâneas). Portanto, em todas as solicitações, é 100,444 ms / 10 = 10,044 ms.
Taxa de transferência - 1338,39 [Kbytes / s] recebidos.
Nas estatísticas de tempo de conexão, você pode observar que muitas solicitações tiveram que esperar alguns segundos. Isso pode ser devido ao servidor da web apache colocar as solicitações na fila de espera.

Em nosso primeiro teste, testamos um aplicativo (ou seja, www.apache.org) hospedado em um servidor diferente. Na parte posterior do tutorial, testaremos nossos aplicativos da web de amostra hospedados no mesmo servidor a partir do qual executaremos os testes ab. Isso é para facilitar o aprendizado e o propósito de demonstração. Idealmente, o nó host e o nó de teste devem ser diferentes para uma medição precisa.

Para melhor aprender ab, você deve comparar e observar como os valores de saída variam para diferentes casos à medida que avançamos neste tutorial.

Traçando a saída do Apache Bench

Aqui, traçaremos o resultado relevante para ver quanto tempo o servidor leva à medida que o número de solicitações aumenta. Para isso, vamos adicionar o-g opção no comando anterior seguida do nome do arquivo (aqui fora.data) no qual os dados de saída ab serão salvos -

$ ab -n 100 -c 10 -g out.data https://www.apache.org/

Vamos agora ver o out.data antes de criarmos um enredo -

$ less out.data

Output

starttime       seconds ctime   dtime   ttime   wait
Tue May 30 12:11:37 2017        1496160697      40      38      77      13
Tue May 30 12:11:37 2017        1496160697      42      38      79      13
Tue May 30 12:11:37 2017        1496160697      41      38      80      13
...

Vamos agora entender os cabeçalhos das colunas no out.data arquivo -

starttime - Esta é a data e hora em que a chamada começou.
seconds - Igual à hora de início, mas no formato de carimbo de data / hora Unix (data -d @ 1496160697 retorna a saída da hora de início).
ctime - Este é o tempo de conexão.
dtime - Este é o tempo de processamento.
ttime - Este é o Tempo Total (é a soma de ctime e dtime, matematicamente ttime = ctime + dtime).
wait - Este é o tempo de espera.

Para uma visualização pictórica de como esses vários itens estão relacionados entre si, dê uma olhada na imagem a seguir -

Se estivermos trabalhando em um terminal ou onde os gráficos não estiverem disponíveis, gnuploté uma ótima opção. Vamos entender isso rapidamente seguindo as etapas a seguir.

Vamos instalar e lançar o gnuplot -

$ sudo apt-get install gnuplot  
$ gnuplot

Output

G N U P L O T
Version 4.6 patchlevel 6    last modified September 2014
Build System: Linux x86_64

Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others

gnuplot home:     http://www.gnuplot.info
faq, bugs, etc:   type "help FAQ"
immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot>

Como estamos trabalhando no terminal e supondo que não haja gráficos disponíveis, podemos escolher o terminal burro que dará saída em ASCII sobre o próprio terminal. Isso nos ajuda a ter uma ideia de como será o nosso gráfico com esta ferramenta rápida. Vamos agora preparar o terminal para o gráfico ASCII.

gnuplot> set terminal dumb

Output

Terminal type set to 'dumb'
Options are 'feed  size 79, 24'

Como nosso terminal gnuplot agora está pronto para o gráfico ASCII, vamos representar graficamente os dados do out.data arquivo -

gnuplot> plot "out.data" using 9  w l

Output

1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
       +      +      +     +      +      +      +"out.data" using 9 ****** +
       |                                                                   |
  1200 ++                       ********************************************
       |     *******************                                           |
  1000 ++    *                                                            ++
       |     *                                                             |
       |     *                                                             |
   800 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   600 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   400 ++   *                                                             ++
       |    *                                                              |
   200 ++   *                                                             ++
       |    *                                                              |
       +****  +      +     +      +      +      +      +     +      +      +
     0 ++-----+------+-----+------+------+------+------+-----+------+-----++
       0      10     20    30     40     50     60     70    80     90    100

Traçamos o ttime, o tempo total (em ms) da coluna 9, em relação ao número de solicitações. Podemos notar que, para as solicitações de dez iniciais, o tempo total foi nos cerca de 100 ms, para os próximos 30 pedidos (a partir de 10 ^° a 40 ^° ), que aumentou para 1100 ms, e assim por diante. Seu enredo deve ser diferente dependendo de seuout.data.

No capítulo anterior, entendemos o uso básico do Apache Bench para testar um site de terceiros. Nesta seção, usaremos essa ferramenta para testar um aplicativo da web em nosso próprio servidor. Para manter o tutorial independente na medida do possível, optamos por instalar um aplicativo Python para fins de demonstração; você pode escolher qualquer outra linguagem como PHP ou Ruby dependendo do seu nível de conhecimento.

Instalando Python

Geralmente, Python é instalado por padrão em servidores Linux.

Instalando o Bottle Framework e criando um aplicativo simples

Bottle é uma microestrutura escrita em python para criar aplicativos da web e pip é um gerenciador de pacotes python. Digite o seguinte comando no terminal para instalar o Bottle -

$ sudo apt-get install python-pip
$ sudo pip install bottle

Vamos agora criar um pequeno aplicativo Bottle. Para isso, crie um diretório e mova dentro dele -

$ mkdir webapp
$ cd webapp

Vamos criar um novo script python, app.py, dentro do diretório webapp -

$ vim app.py

Agora, escreva o seguinte código no arquivo app.py -

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello')
def hello():
   return "Hello World!"

run(app, host = 'localhost', port = 8080)

Depois de adicionar as linhas acima, salve e feche o arquivo. Depois de salvar o arquivo, podemos executar o script Python para iniciar o aplicativo -

$ python app.py

Output

Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.

Esta saída mostra que nosso aplicativo está sendo executado na máquina local no host http://localhost e ouvindo no porto 8080.

Vamos verificar se nosso aplicativo está respondendo adequadamente às solicitações HTTP. Como este terminal não pode receber nenhuma entrada sem parar de servir o aplicativo Bottle, precisamos fazer o login em nosso VPS com outro terminal. Depois de fazer o login no VPS com outro terminal, você pode navegar até seu aplicativo digitando o seguinte código no novo terminal.

$ lynx http://localhost:8080/

Lynx é um navegador de linha de comando e geralmente é instalado por padrão em várias distribuições Linux como Debian e Ubuntu. Se você vir a seguinte saída, significa que seu aplicativo está funcionando bem.

Output

Se você vir a saída acima, significa que nosso aplicativo está ativo e pronto para teste.

Testando o aplicativo com o servidor Web de desenvolvimento

Observe que há um bug no ab e não é possível testar o aplicativo no host local. Portanto, vamos alterar o host de localhost para 127.0.0.1 no arquivo app.py. Portanto, o arquivo será alterado para o seguinte -

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello')
def hello():
   return "Hello World!"

run(app, host = '127.0.0.1', port = 8080)

Vamos agora testar nosso aplicativo digitando o seguinte comando no mesmo terminal em que executou o comando lynx -

$ ab -n 100 -c 10  http://127.0.0.1:8080/hello

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        WSGIServer/0.1
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        12 bytes

Concurrency Level:      10
Time taken for tests:   0.203 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      16500 bytes
HTML transferred:       1200 bytes
Requests per second:    493.78 [#/sec] (mean)
Time per request:       20.252 [ms] (mean)
Time per request:       2.025 [ms] (mean, across all concurrent requests)
Transfer rate:          79.56 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:     1    6  28.2      2     202
Waiting:        1    6  28.2      2     202
Total:          1    6  28.2      2     202

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      2
  95%      2
  98%    202
  99%    202
 100%    202 (longest request)

Enquanto a saída no primeiro terminal será (100 vezes) como segue -

...
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12   
...

Você pode observar como os vários valores do resultado ab mudaram em comparação com o teste inicial.

Testando o aplicativo com um servidor Web multi-threaded

Nos testes anteriores de ab, usamos o servidor da web padrão empacotado no framework Bottle.

Agora vamos mudar o servidor da web padrão de thread único por um multi-thread. Portanto, vamos instalar uma biblioteca de servidor web multithread comocherrypy ou gunicorne diga a Bottle para usá-lo. Escolhemos o gunicorn para o propósito de demonstração aqui (você pode escolher outro também) -

$  sudo apt-get install gunicorn

E modifique o arquivo, ou seja, mude do servidor da web padrão para gunicorn -

...
run(server = 'gunicorn'...)
...

Vamos testar o aplicativo no segundo terminal.

$ ab -n 100 -c 10  http://127.0.0.1:8080/hello

Output

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        gunicorn/19.0.0
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /hello
Document Length:        12 bytes

Concurrency Level:      10
Time taken for tests:   0.031 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      17200 bytes
HTML transferred:       1200 bytes
Requests per second:    3252.77 [#/sec] (mean)
Time per request:       3.074 [ms] (mean)
Time per request:       0.307 [ms] (mean, across all concurrent requests)
Transfer rate:          546.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.9      0       4
Processing:     1    2   0.7      3       4
Waiting:        0    2   0.8      2       3
Total:          2    3   0.6      3       5
WARNING: The median and mean for the initial connection time are not within a normal
        deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      4
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

Observe como as solicitações por segundo aumentaram de 493 para 3252. Isso significa que o gunicorn é adequado como um servidor de produção para aplicativos python.

Neste capítulo, aprenderemos como testar vários URLs simultaneamente. Para isso, precisaremos editar nosso arquivo de aplicativo, app.py, para incluir dois URLs -

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello1')
def hello():
   return "Hello World! It is first URL."

@app.route('/hello2')
def hello():
   return "Hello World! It is second URL."

run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)

Criando um Script de Shell Simples

Você pode fazer isso criando um script de shell, com várias chamadas ab. Crie um arquivo test.sh e adicione as seguintes linhas a ele -

ab -n 100 -c 10 http://127.0.0.1:8080/hello1 
ab -n 100 -c 10 http://127.0.0.1:8080/hello2

Depois de adicionar as linhas acima, salve e feche o arquivo. Torne o arquivo executável -

chmod u+x test.sh

Vamos agora executar o script -

./test.sh

Para evitar a repetição e o propósito de clareza, mostraremos apenas o relevante da saída ab, indicando por pontos qual parte foi omitida, como a seguir.

Resultado

.
.
.
Document Path:          /hello1
Document Length:        732 bytes

Concurrency Level:      10
Time taken for tests:   0.040 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      90000 bytes
HTML transferred:       73200 bytes
Requests per second:    2496.13 [#/sec] (mean)
Time per request:       4.006 [ms] (mean)
Time per request:       0.401 [ms] (mean, across all concurrent requests)
Transfer rate:          2193.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0       3
Processing:     1    3   1.0      4       5
Waiting:        0    3   1.2      4       4
Total:          1    4   0.6      4       5
WARNING: The median and mean for the processing time are not within a normal deviation
        These results are probably not that reliable.
.
.
.

Shell Script para salvar a saída do Apache Bench em um arquivo

Você pode salvar a saída do Apache Bench em arquivo criando um script de shell, com várias chamadas ab. No final de cada linha, coloque um&;isso faz com que o comando seja executado em segundo plano e permite que o próximo comando inicie sua execução. Você também desejará redirecionar a saída para um arquivo para cada url usando <filename>. Por exemplo, nosso arquivo test.sh terá a seguinte aparência após a modificação -

$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt &
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &

Aqui, test1.txt e test2.txt são os arquivos para salvar os dados de saída.

Você pode verificar se o script acima criou dois arquivos, test1.txt e test2.txt, que contém a saída ab para os respectivos URLs -

$ ls -l

Resultado

...
-rw-r--r-- 1 root root  5225 May 30 12:11 out.data
-rwxr--r-- 1 root root   118 Jun 10 12:24 test.sh
-rw-r--r-- 1 root root  1291 Jun 10 12:31 test1.txt
-rwxr--r-- 1 root root    91 Jun 10 13:22 test2.sh
-rw-r--r-- 1 root root  1291 Jun 10 12:31 test2.txt
...

Situação de alerta

Ao usar ab, você deve estar alerta ao teste que falhou sem avisar. Por exemplo, se você verificar uma URL errada, poderá obter algo semelhante ao seguinte (alteramos deliberadamente a porta aqui).

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:805/

Resultado

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done

Server Software:
Server Hostname:        127.0.0.1
Server Port:            805

Document Path:          /
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.002 seconds
Complete requests:      100
Failed requests:        150
   (Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests:    0
Total transferred:      0 bytes
HTML transferred:       0 bytes
Requests per second:    44984.26 [#/sec] (mean)
Time per request:       0.222 [ms] (mean)
Time per request:       0.022 [ms] (mean, across all concurrent requests)
Transfer rate:          0.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.2      0       0
Waiting:        0    0   0.0      0       0
Total:          0    0   0.2      0       0

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%      0
  99%      0
 100%      0 (longest request)

Neste capítulo, entenderemos a preparação necessária para testar páginas dinâmicas. Uma página da web dinâmica do lado do servidor é uma página da web cuja construção é controlada por um servidor de aplicativos que processa scripts do lado do servidor. O banco de dados do Apache só pode carregar o teste da página da web dinâmica do lado do servidor.

Nível de simultaneidade e o número total de solicitações

O nível de simultaneidade deve ser inferior ao número total de solicitações.

$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Output

ab: Cannot use concurrency level greater than total number of requests
Usage: ab [options] [http[s]://]hostname[:port]/path

Uso de Bandeiras

Nesta seção, descreveremos o uso de alguns sinalizadores importantes com o comando ab. Usaremos os termos, opções e sinalizadores, alternadamente.

Detalhado -v

A opção detalhada pode ser usada para analisar e depurar se houver vários números de solicitações com falha. Uma indicação comum de falha do teste de carga é que o teste termina muito rápido e fornece um bom número de solicitação por segundo valor. Mas será um benchmark errado. Para identificar o sucesso ou o fracasso, você pode usar o-v 2opção que irá despejar o corpo e cabeçalho de cada resposta para a saída do terminal. O comando a seguir descreve um caso de uso -

$ ab -n 1 -v 2 http://www.generic-example-URL.com/

Output

LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687

Claro, se você estiver testando respostas variáveis ou retornando códigos HTTP diferentes de 200 no caso de qualquer erro, você deve simplesmente ignorar a verificação de comprimento com o -lopção. Em breve veremos HTTP diferente de 200 quando lançarmos um aplicativo web2py nos capítulos subsequentes.

Keep-alive -k

Quando o cliente envia uma solicitação HTTP, a conexão é feita com o servidor, o servidor envia a resposta e a conexão é fechada após o envio da solicitação. Este ciclo continua com cada solicitação. No entanto, com a configuração keep-alive (também conhecida como conexões persistentes), o cliente mantém uma conexão TCP subjacente aberta para facilitar várias solicitações e respostas; isso elimina o tempo de inicialização de conexão lento e caro que, de outra forma, estaria presente.

Comprimento variável do documento -l

Se a página da web tiver comprimento variável, você deve usar a opção -l. O Apache Bench não relata erros se o comprimento das respostas não for constante. Isso pode ser útil para páginas dinâmicas.

Uso da opção -r

Como forçar ab para não sair ao receber erros? Você deve usar a opção-r. Sem esta opção, seu teste pode ser interrompido assim que qualquer solicitação atingir o erro de soquete. Porém, com esta opção, os erros serão reportados no cabeçalho erros falhados, mas o teste continuará até o final.

Uso da opção -H

Esta opção é usada para adicionar uma linha de cabeçalho arbitrária. O argumento está normalmente na forma de uma linha de cabeçalho válida, contendo um par de valores de campo separados por dois pontos (ou seja, “Aceitar Codificação: zip / zop; 8 bits”).

Uso da opção -C

Na seção a seguir, aprenderemos em detalhes como usar as opções acima em combinação com a opção de usar o valor do cookie, ou seja, o -Copção. A opção -C está normalmente na forma de umname = valuepar. Este campo pode ser repetido.

Usando Cookie de Sessão com Apache Bench

Para entender como usar o cookie com o Apache Bench, precisamos de uma página da web que tenta definir um cookie. Um bom exemplo é o aplicativo web2py, que é um framework web python.

Instalando web2py

Vamos instalar rapidamente outro aplicativo python web2py. Você pode ler mais sobre como usá-lo no Web2py Framework Overview .

Python é geralmente instalado por padrão nos servidores Ubuntu e Debian. Portanto, um requisito já foi atendido para executar o web2py com êxito.

No entanto, precisamos instalar o pacote de descompactação para extrair os arquivos de origem do web2py do arquivo zip que iremos baixar -

$ sudo apt-get update
$ sudo apt-get install unzip

Vamos obter o framework web2py no site do projeto. Faremos o download para nossa pasta de início -

$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zip

Agora, podemos descompactar o arquivo que acabamos de baixar e mover para dentro -

$ unzip web2py_src.zip
$ cd web2py

Para executar o web2py, você não precisa instalá-lo. Uma vez dentro do diretório web2py, você pode executá-lo digitando o seguinte comando -

$python web2py.py

Se tudo for bem-sucedido, você verá a seguinte saída, onde será solicitado que você escolha uma senha para a IU administrativa -

web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:

please visit:
        http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py server

No entanto, você precisa estar ciente do fato de que a interface da web iniciada está acessível apenas na máquina local.

A partir da saída, você pode entender que para parar o servidor web, você terá que digitar “CTRL-C” no terminal instantâneo. Por outro lado, para parar o servidor web2py no outro terminal relacionado ao mesmo VPS, você pode inserir o comando kill -SIGTERM <PID>, onde <PID> é o ID do processo para o servidor web2py, que neste caso é 23904.

Cookie de sessão de web2py

Se uma página for acessível apenas por um usuário conectado, não acessível diretamente a partir da página de login, nesse caso você pode usar o -Cbandeira. Este sinalizador define um cookie para o comando ab. Mas você deve obter o valor do cookie do identificador de sessão de uma sessão válida. Como conseguir isso? Vários tutoriais online irão guiá-lo em direção às ferramentas de desenvolvedor do navegador Chrome (ou Mozilla). Mas em nosso caso de teste, como o aplicativo está disponível apenas na linha de comando, usaremos o navegador lynx para obter o valor.

Vamos obter o valor do cookie de uma sessão primeiro. Abra outro terminal e digite o seguinte comando -

$ lynx http://127.0.0.1:8000/

Em resposta ao comando acima, o lynx pedirá sua permissão para aceitar o cookie do servidor web2py, conforme mostrado na imagem abaixo.

Anote o valor do cookie antes de digitar ypara aceitar o cookie. Agora, o terminal será semelhante à seguinte imagem - site no terminal!

Tendo obtido o valor do cookie, iremos agora executar o teste ab. Para isso teremos que abrir o terceiro terminal (veja a imagem abaixo) -

Agora, vamos usar o sinalizador -C no terceiro terminal -

$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/

Resultado

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        66 bytes

Concurrency Level:      10
Time taken for tests:   0.051 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    1968.12 [#/sec] (mean)
Time per request:       5.081 [ms] (mean)
Time per request:       0.508 [ms] (mean, across all concurrent requests)
Transfer rate:          532.39 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.9      2       4
Processing:     0    3   0.9      3       5
Waiting:        0    2   1.1      2       4
Total:          4    5   0.7      5       7

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      5
  75%      5
  80%      6
  90%      6
  95%      6
  98%      7
  99%      7
 100%      7 (longest request)

Na saída acima, notamos vários pontos. Primeiro, o web2py usa o servidor web Rocket . Também observamos que estamos recebendo 'Respostas não 2xx' além dos títulos discutidos anteriormente na saída. Em geral, o protocolo Http responde a uma solicitação usando um código de resposta, e qualquer coisa dentro da faixa de 200 significa 'ok', e o resto corresponde a algum problema. Por exemplo, 400s são erros relacionados a recursos, como 404 Arquivo não encontrado. 500s correspondem a erros do servidor. Em nosso caso instantâneo, não há erro em nenhum lugar, exceto quando estamos usando a opção -C. Ele pode ser suprimido usando a opção -l conforme já descrito.

Verificando a página do administrador

Nesta seção, entenderemos como verificar a página de administração. Para fins de comparação, vamos testar outro URL do aplicativo web2py -

$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/admin

Resultado

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /admin
Document Length:        8840 bytes

Concurrency Level:      10
Time taken for tests:   2.077 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      926700 bytes
HTML transferred:       884000 bytes
Requests per second:    48.14 [#/sec] (mean)
Time per request:       207.749 [ms] (mean)
Time per request:       20.775 [ms] (mean, across all concurrent requests)
Transfer rate:          435.61 [Kbytes/sec] received

Connection Times (ms)
          min  mean[+/-sd] median   max
Connect:        0    1   3.2      0      12
Processing:    62  204  52.2    199     400
Waiting:       61  203  52.0    199     400
Total:         62  205  54.3    199     411

Percentage of the requests served within a certain time (ms)
  50%    199
  66%    211
  75%    220
  80%    226
  90%    264
  95%    349
  98%    381
  99%    411
 100%    411 (longest request)

Você deve, em particular, observar as respectivas estatísticas na seção "Tempos de conexão" e "Porcentagem das solicitações atendidas ..." de http://127.0.0.1:8000/ e http://127.0.0.1:8000/admin. Há uma enorme diferença.

Usando a opção de limite de tempo

Geralmente, a opção Timelimit é complicada. Vamos entender isso a partir do manual de ab , que é bastante explicativo -

-t timelimit
Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.
Use this to benchmark the server within a fixed total amount of time.
Per default there is no timelimit.

Vamos fazer um teste com esta opção. Notaremos nossas observações após analisar a saída -

$ ab -n 100 -c 10 -t 60   http://127.0.0.1:8000/

Resultado

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        66 bytes

Concurrency Level:      10
Time taken for tests:   22.547 seconds
Complete requests:      50000
Failed requests:        0
Non-2xx responses:      50000
Total transferred:      13850000 bytes
HTML transferred:       3300000 bytes
Requests per second:    2217.61 [#/sec] (mean)
Time per request:       4.509 [ms] (mean)
Time per request:       0.451 [ms] (mean, across all concurrent requests)
Transfer rate:          599.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   0.8      2       8
Processing:     0    2   3.2      2     218
Waiting:        0    2   3.2      2     218
Total:          2    4   3.1      4     220

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      5
  90%      5
  95%      5
  98%      7
  99%      8
 100%    220 (longest request)

Observe que a saída mostra que esta opção substitui o número de solicitações especificadas pelo -nopção e continua até as solicitações de 50K. No entanto, como as solicitações foram tratadas muito rapidamente, ab terminou assim que a marca de 50k foi alcançada - em 22 segundos (consulte o título Tempo gasto para testes) no caso presente.

Você pode testar o mesmo comando substituindo http://127.0.0.1:8000/ com http://127.0.0.1:8000/admin (presumindo que seja nosso aplicativo web2py) ou um site de terceiros como https://www.apache.org/, observe a diferença nas estatísticas.

Lista de verificação antes de realizar o teste de carga

Existem algumas verificações que o ajudarão a executar o teste com sucesso e medir o desempenho com precisão. Considere as seguintes condições antes de realizar o teste de carga -

Certifique-se de que nenhum módulo Python extra seja carregado.
Para evitar o esgotamento da porta TCP / IP, você deve esperar de 2 a 3 minutos antes de passar para outro teste ab.
Certifique-se de que o número de conexões simultâneas seja menor do que os Threads de trabalho do Apache.
Você deve reiniciar o servidor antes de realizar outro teste, se o Apache ou o python travar.

Neste capítulo, descreveremos as várias combinações de -n e -c com as sinalizações importantes para aumentar gradualmente a carga em seu servidor da web.

Você deve se concentrar principalmente em como as seguintes métricas mudam conforme você aumenta a carga -

Solicitações por segundo
Tempos de conexão (ms)
Porcentagem das solicitações atendidas em um determinado período (ms)

Você também deve observar o valor limite quando o servidor começa a travar e você começa a receber solicitações com falha.

1 usuário simultâneo fazendo 100 acessos à página

Vamos fazer 100 carregamentos de página sequenciais por um único usuário -

$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Resultado

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        Variable

Concurrency Level:      1
Time taken for tests:   0.045 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    0
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    2206.24 [#/sec] (mean)
Time per request:       0.453 [ms] (mean)
Time per request:       0.453 [ms] (mean, across all concurrent requests)
Transfer rate:          596.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.0      0       0
Waiting:        0    0   0.0      0       0
Total:          0    0   0.0      0       1

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      1
  95%      1
  98%      1
  99%      1
 100%      1 (longest request)

5 usuários simultâneos, cada um fazendo 10 acessos à página

Este caso corresponde a um pico de carga em um site que obtém cerca de 50.000+ acessos por mês.

$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Nas saídas subsequentes a seguir, omitiremos o cabeçalho comum para fins de clareza.

Resultado

...
Requests per second:    2009.24 [#/sec] (mean)
Time per request:       2.488 [ms] (mean)
Time per request:       0.498 [ms] (mean, across all concurrent requests)
Transfer rate:          543.52 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.5      1       2
Processing:     0    1   0.5      1       2
Waiting:        0    1   0.5      1       1
Total:          2    2   0.4      3       3
ERROR: The median and mean for the total time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      3
  95%      3
  98%      3
  99%      3
 100%      3 (longest request)

10 usuários simultâneos, cada um fazendo 10 acessos à página

Este teste corresponde a 100 carregamentos de página por 10 usuários simultâneos diferentes, cada usuário fazendo 10 carregamentos de páginas sequenciais.

$ ab  -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Resultado

...
Requests per second:    2225.68 [#/sec] (mean)
Time per request:       4.493 [ms] (mean)
Time per request:       0.449 [ms] (mean, across all concurrent requests)
Transfer rate:          602.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   1.0      2       3
Waiting:        0    1   1.0      2       3
Total:          4    4   0.3      4       4
WARNING: The median and mean for the waiting time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      4
  90%      4
  95%      4
  98%      4
  99%      4
 100%      4 (longest request)

20 usuários simultâneos, cada um fazendo 20 acessos à página

Este teste corresponde a 400 carregamentos de páginas por 20 usuários simultâneos diferentes, cada usuário fazendo 20 carregamentos de páginas sequenciais.

$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/

Resultado

...
Requests per second:    1619.96 [#/sec] (mean)
Time per request:       12.346 [ms] (mean)
Time per request:       0.617 [ms] (mean, across all concurrent requests)
Transfer rate:          438.21 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    6   2.3      6      10
Processing:     1    5   2.9      5      10
Waiting:        0    5   2.9      5       9
Total:         10   11   0.6     11      12

Percentage of the requests served within a certain time (ms)
  50%     11
  66%     11
  75%     12
  80%     12
  90%     12
  95%     12
  98%     12
  99%     12
 100%     12 (longest request)

30 usuários simultâneos, cada um fazendo 30 acessos à página

Este teste corresponde a 900 carregamentos de página por 30 usuários simultâneos diferentes, cada usuário fazendo 30 carregamentos de páginas sequenciais.

$ ab  -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Resultado

...
Requests per second:    2283.45 [#/sec] (mean)
Time per request:       13.138 [ms] (mean)
Time per request:       0.438 [ms] (mean, across all concurrent requests)
Transfer rate:          617.69 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    6   2.7      6      11
Processing:     1    6   3.1      6      11
Waiting:        0    5   3.2      5      10
Total:         11   12   0.5     12      13

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     12
  80%     12
  90%     13
  95%     13
  98%     13
  99%     13
 100%     13 (longest request)

Agora aprendemos como aumentar a carga gradualmente no site e testar seu desempenho.

Neste capítulo, compararemos as saídas com e sem sinalizadores. Vamos ver como o uso de sinalizadores apropriados pode aumentar o desempenho de seu aplicativo da web. Antes disso, precisamos entender como se sua aplicação for simples você pode não notar a diferença. Como é o caso de nosso aplicativo simples, com sinalizadores e sem sinalizadores. Então vamos realizar o mesmo teste comhttps://www.apache.org/ URL e veja a diferença.

Testando nosso aplicativo sem sinalizadores

Nesta seção, entenderemos como testar nosso aplicativo sem sinalizadores.

$ ab -n 100 -c 10 http://127.0.0.1:8000/

Resultado

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.244 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    0
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    2208.77 [#/sec] (mean)
Time per request:       4.527 [ms] (mean)
Time per request:       0.453 [ms] (mean, across all concurrent requests)
Transfer rate:          597.49 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   0.7      2       4
Waiting:        0    2   1.0      2       3
Total:          4    4   0.3      4       5

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      5
  80%      5
  90%      5
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

Testando nosso aplicativo com sinalizadores

Nesta seção, entenderemos como testar nosso aplicativo com sinalizadores.

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

Resultado

...
Requests per second:    2277.07 [#/sec] (mean)
Time per request:       4.392 [ms] (mean)
Time per request:       0.439 [ms] (mean, across all concurrent requests)
Transfer rate:          615.97 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   0.7      2       4
Waiting:        0    2   1.0      2       3
Total:          4    4   0.2      4       5

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      4
  90%      5
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

Podemos simplesmente notar que não há muita diferença entre as estatísticas de saída.

Testando o site da organização Apache sem sinalizadores

Vamos agora ver como testar o site da organização Apache sem sinalizadores.

$ ab -n 100 -c 10 http://www.apache.org/

Resultado

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            80

Document Path:          /
Document Length:        58433 bytes

Concurrency Level:      10
Time taken for tests:   1.498 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5877500 bytes
HTML transferred:       5843300 bytes
Requests per second:    66.74 [#/sec] (mean)
Time per request:       149.840 [ms] (mean)
Time per request:       14.984 [ms] (mean, across all concurrent requests)
Transfer rate:          3830.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       12  110 295.2     12    1012
Processing:    37   38   0.5     38      39
Waiting:       12   13   0.3     13      15
Total:         49  147 295.4     50    1051

Percentage of the requests served within a certain time (ms)
  50%     50
  66%     50
  75%     50
  80%     50
  90%    816
  95%   1050
  98%   1051
  99%   1051
 100%   1051 (longest request)

Testando o site da organização Apache com sinalizadores

Vamos agora testar o site da organização Apache com sinalizadores.

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://www.apache.org/

Resultado

...
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.357 seconds
Complete requests:      100
Failed requests:        0
Keep-Alive requests:    100
Total transferred:      1358510 bytes
HTML transferred:       1317700 bytes
Requests per second:    280.28 [#/sec] (mean)
Time per request:       35.678 [ms] (mean)
Time per request:       3.568 [ms] (mean, across all concurrent requests)
Transfer rate:          3718.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.7      0      12
Processing:    14   17  21.3     15     227
Waiting:       14   17  21.3     14     227
Total:         14   18  21.5     15     227

Percentage of the requests served within a certain time (ms)
  50%     15
  66%     15
  75%     15
  80%     15
  90%     27
  95%     28
  98%     29
  99%    227
 100%    227 (longest request)

Você pode simplesmente observar como a solicitação por segundo aumentou com o uso de sinalizadores. No caso presente, é particularmente devido ao uso de-H "Accept-Encoding: gzip, desinflar porque este sinalizador diz ao servidor Apache para atender às solicitações em gzipped formato.

Considerando os resultados do Apache Bench

Alguns pontos importantes precisam ser considerados quando se trata dos resultados do Apache Bench. Isso nos ajudará a projetar nossa estratégia geral para remover os gargalos em nosso aplicativo e melhorar seu desempenho.

Precisamos de solicitações por segundo. Isso nos dá uma ideia de como a configuração do nosso servidor da web está funcionando; quanto maior o número, melhor é o desempenho. Em seguida, vêm os tempos de conexão (ms) e a porcentagem de solicitações atendidas. Você pode ter que ajustar as configurações do seu servidor web para alterar essas métricas para o desempenho desejado.

Verifique se há erros nos logs de erro do Apache ou do servidor web ou logs (gerais) usados. Conforme você aumentará sua carga, as coisas começarão a engasgar: problemas de memória começarão a surgir. Muitos scripts Python começarão a travar se não forem escritos com a simultaneidade em mente.

Você precisa descobrir qual é o valor de simultaneidade crítico acima do qual seu servidor da web trava e / ou atinge o tempo limite? Normalmente, isso deve acontecer em um nível de simultaneidade bastante alto. Se este valor for baixo, algo está errado e você precisa ajustar essas configurações para mais ou para menos.

Conclusão

Neste tutorial, aprendemos como o Apache Bench pode ser usado para testar a carga de qualquer site ou aplicativo da web. O Apache Bench pode ser uma ferramenta muito valiosa para determinar como a configuração do servidor de aplicativos da web deve ser melhorada, para reduzir gargalos e aumentar o desempenho. Agora que você está familiarizado com o uso básico do Apache Bench, pode começar criando novos planos de teste para medir o desempenho de seus aplicativos em vários cenários.

↰ Previous page