Por que o ab está errando com: apr_socket_recv: Conexão redefinida pelo peer (54) no OSX?

2

Estou tentando usar ab para fazer o benchmark de um cluster de 4 ubuntu boxes executando nginx que são balanceadas por outra caixa do ubuntu executando haproxy . Para os interessados, acompanho a série de tutoriais sysadmincasts . Não consigo comparar com êxito o cluster do meu laptop executando osx:

➜  ~ uname -a
Darwin mbp 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64
➜  ~ system_profiler SPSoftwareDataType
Software:

    System Software Overview:

      System Version: OS X 10.11.6 (15G1004)
      Kernel Version: Darwin 15.6.0
      Boot Volume: Untitled
      Boot Mode: Normal
      Computer Name: Max’s MacBook Pro
      User Name: Max Bigras (max)
      Secure Virtual Memory: Enabled
      System Integrity Protection: Disabled
      Time since boot: 4 days 6:27
➜  ~ ab -n 10000 -c 25 http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
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)
apr_socket_recv: Connection reset by peer (54)

Eu encontrei outro post que mencionou a possibilidade de problema com limites de soquete em osx . No entanto, quando tentei a solução mencionada, ainda não funcionou:

➜  ~ sysctl kern.maxfiles
kern.maxfiles: 1048600
➜  ~ ulimit -S -n
1048576
➜  ~ ab -n 10000 -c 25 http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
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)
apr_socket_recv: Connection reset by peer (54)
Total of 25 requests completed

Sei que estou atingindo meus servidores pelo menos um pouco porque verifiquei os arquivos de log de um dos nós da Web executando nginx

sshing na web1 (uma caixa do Ubuntu que executa o nginx):

vagrant@web1:~$ echo $USER
vagrant
vagrant@web1:~$ sudo tail -f /var/log/nginx/access.log
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:53:25 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:54:59 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:54:59 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:54:59 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:54:59 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:54:59 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:54:59 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:54:59 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:54:59 +0000] "GET / HTTP/1.0" 200 632 "-" "ApacheBench/2.3"
10.0.15.11 - - [02/Oct/2016:06:55:09 +0000] "GET / HTTP/1.1" 200 632 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"

tentando ab novamente no osx:

➜  ~ echo $USER
max
➜  ~ date
Sat Oct  1 23:54:54 PDT 2016
➜  ~ ab -n 10000 -c 25 http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
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)
apr_socket_recv: Connection reset by peer (54)
Total of 41 requests completed
➜  ~ date
Sat Oct  1 23:55:02 PDT 2016
➜  ~

Acima você pode ver que, além de tentar avaliar o cluster, eu também bato nele com o meu navegador, como pode ser visto na parte inferior em /var/log/nginx/access.log . Definitivamente, parece que o problema tem que haver um limite no número de pedidos que posso fazer. Se eu diminuir o número de pedidos e o valor de simultaneidade, então funciona:

➜  ~ ab -n 100 -c 1 http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
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:        nginx
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /
Document Length:        632 bytes

Concurrency Level:      1
Time taken for tests:   0.218 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      83800 bytes
HTML transferred:       63200 bytes
Requests per second:    458.17 [#/sec] (mean)
Time per request:       2.183 [ms] (mean)
Time per request:       2.183 [ms] (mean, across all concurrent requests)
Transfer rate:          374.95 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       2
Processing:     1    2   0.8      2       5
Waiting:        1    2   0.7      1       5
Total:          1    2   0.9      2       6
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%      2
  66%      2
  75%      2
  80%      2
  90%      3
  95%      4
  98%      6
  99%      6
 100%      6 (longest request)

Então, como eu configuro o osx para que eu possa testar 10000 solicitações com uma simultaneidade de 25 usando ab ?

Editar: adicione nginx.conf

vagrant@web1:~$ cat /etc/nginx/nginx.conf
# Ansible managed: /home/vagrant/templates/nginx.conf.j2 modified on 2016-09-11 14:17:19 by vagrant on mgmt
user              www-data;

worker_processes  1;
pid        /var/run/nginx.pid;
worker_rlimit_nofile 1024;

events {
    worker_connections  512;
}


http {

        include /etc/nginx/mime.types;
        default_type application/octet-stream;
        tcp_nopush "on";
        tcp_nodelay "on";
        #keepalive_timeout "65";
        access_log "/var/log/nginx/access.log";
        error_log "/var/log/nginx/error.log";
        server_tokens off;
        types_hash_max_size 2048;

        # https://philio.me/backend-server-host-name-as-a-custom-header-with-nginx/
        add_header X-Backend-Server $hostname;

        # disable cache used for testing
        add_header Cache-Control private;
        add_header Last-Modified "";
        sendfile off;
        expires off;
        etag off;

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}
    
por mbigras 02.10.2016 / 09:04

2 respostas

2

Existe um problema com ab no OSX. Vou escrever uma resposta mais limpa amanhã, mas por enquanto essas fontes com marcadores devem ajudar quem estiver interessado, usando ab para o tutorial sysadmincasts. O tl; dr é instalar ab no nó mgmt que está rodando o Ubuntu e então usar uma porta reversa para a frente quando estiver entrando, veja as fontes para mais detalhes.

  • ab não funciona em osx
  • faça:
    • inverter a porta para a frente ao sshing no nó mgmt link
    • encaminhar o mgmt para a frente no link do Vagrantfile
    • veja o link PR
  • não faça:

por 04.10.2016 / 09:41
1

O erro Connection reset by peer significa que seu servidor da web fechou a conexão antes de responder à sua solicitação. Portanto, a carga é muito grande para o seu servidor e começa a perder conexões.

Você precisa estudar sua configuração de servidor para ver por que isso acontece. Estude seus arquivos de log.

Este erro não acontece devido ao seu lado do cliente.

    
por 03.10.2016 / 15:21