☰

Solução de problemas de conexões com falha do Apache

tag-icon • tag-icon apache-2.2 ssl connection
Solução de problemas de conexões com falha do Apache

Estou tentando solucionar algumas falhas de conexão estranhas e intermitentes com o Apache. Percebi o problema quando os usuários reclamaram que partes do aplicativo da web que hospedamos não estavam funcionando. A depuração revelou que as solicitações AJAX não estavam retornando os dados XML ou JSON que o aplicativo JavaScript esperava. O aplicativo é servido por SSL.

Quando eu me testava, via falhas intermitentes e o Firebug mostrava que o comprimento da resposta era zero ou a conexão parecia falhar completamente. Os logs do aplicativo no servidor não mostraram problemas, inclusive quando o Firebug relatou que a resposta estava vazia – o log do aplicativo no servidor mostrou que os dados foram enviados.

Seguindo um palpite, acionei o apachebench ( ab) e fiquei surpreso ao encontrar algumas falhas de conexão:

[jnet@Stan ~]$ ab -v 1 -n 1000 -c 10 $url
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking workingman.smart-safe-secure.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.2.3
Server Hostname:        workingman.smart-safe-secure.com
Server Port:            443
SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256

Document Path:          /
Document Length:        659 bytes

Concurrency Level:      10
Time taken for tests:   104.086 seconds
Complete requests:      1000
Failed requests:        2
   (Connect: 2, Receive: 0, Length: 0, Exceptions: 0)
Write errors:           0
Total transferred:      945000 bytes
HTML transferred:       659000 bytes
Requests per second:    9.61 [#/sec] (mean)
Time per request:       1040.855 [ms] (mean)
Time per request:       104.086 [ms] (mean, across all concurrent requests)
Transfer rate:          8.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      356  844 215.7    840    2268
Processing:    68  194 138.9    128    1483
Waiting:       67  178 122.0    116    1426
Total:        494 1039 241.8    993    2623

Percentage of the requests served within a certain time (ms)
  50%    993
  66%   1039
  75%   1101
  80%   1162
  90%   1407
  95%   1492
  98%   1626
  99%   1718
 100%   2623 (longest request)

Essas solicitações eram para uma página HTML estática, portanto meu aplicativo PHP não parece ser o problema aqui. A execução dos testes em HTTP normal (não SSL) não produziu nenhuma falha . Não sei o que poderia estar acontecendo... nem tenho certeza de como solucionar o problema a partir daqui. Terei prazer em postar a configuração do httpd.conf, apenas deixe-me saber quais partes ajudariam. O servidor é Apache/2.2.3 (CentOS), com mpm_worker e mod_fastcgi...

ATUALIZAR: Acabei de fazer meu primeiro teste ab retornar 2 falhas de conexão em HTTP normal, para a mesma página HTML. Parece que SSL não é o problema, afinal ...

ATUALIZAÇÃO 2: É possível que seja algum tipo de problema de rede, porque não consigo replicar isso usando abem um servidor no mesmo data center, nem consigo replicar isso usando abno host local. No entanto, fazer ping no servidor em questão a partir da minha estação de trabalho mostra 0% de perda de pacotes... Portanto, não tenho certeza de quais etapas tomar a seguir.

ATUALIZAÇÃO 3: Caso ajude, se eu executar abo benchmark em um túnel SSH, não recebo falhas... então talvez seja um problema de rede em vez de um problema do Apache...

Responder1

Quando você diz que funciona muito bem quando as solicitações são feitas no mesmo datacenter ou quando você usa um túnel ssh, acho que pode ser algum tipo de modelagem entre seu site remoto no datacenter.
Como se icmp e ssh (e outros) fossem mais priorizados que http. Portanto, se a WAN ficar sobrecarregada, o roteador poderá interromper o tráfego HTTP. Geralmente o SSH é priorizado porque precisa de alta interatividade, enquanto o FTP tem menos prioridade, pois é a transferência de arquivos.
Pergunte à sua equipe de rede se há algum Shaping ou QOS em vigor.

Outra coisa me diz que o problema pode ser que o tempo de conexão é de 356 a 2268. 356 é bem lento, acho que quando faz túnel com SSH é menos que isso. e uma diferença tão alta entre min e max me diz que alguns pacotes provavelmente foram descartados (devido ao QOS/Shaping) e a retransmissão é necessária (portanto, o tempo de conexão é mais lento)

informação relacionada