Preparação para testar páginas dinâmicas

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 normalmente tem a 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 no servidor 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 pode ser acessada 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 só puder ser acessada 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.