Solucionando problemas de conexões com falha do Apache

2

Estou tentando solucionar algumas falhas estranhas e intermitentes de conexão com o apache. Percebi o problema quando os usuários reclamavam que partes do aplicativo da Web que hospedávamos não estavam funcionando. A depuração revelou que as solicitações do AJAX não estavam retornando os dados XML ou JSON que o aplicativo JavaScript estava esperando. A aplicação é servida por SSL.

Quando eu me testava, eu observava falhas intermitentes, e o Firebug mostrava que o tamanho da resposta era zero ou a conexão parecia falhar completamente. Os logs do aplicativo no servidor não mostraram problemas, incluindo quando o Firebug relatou que a resposta estava vazia - o log do aplicativo no servidor mostrou que os dados haviam sido enviados.

Em um palpite, liguei 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, então meu aplicativo PHP não parece ser o problema aqui. A execução dos testes sobre o HTTP normal (não-ssl) não produziu falhas em todos . Não sei o que poderia estar acontecendo ... nem tenho certeza de como solucionar problemas daqui. Terei prazer em postar a configuração do httpd.conf, apenas deixe-me saber quais partes ajudariam. Servidor é Apache / 2.2.3 (CentOS), com mpm_worker e mod_fastcgi ...

UPDATE : Acabei de ter meu primeiro teste de ab retornando 2 falhas de conexão através do HTTP normal, para a mesma página HTML. Então, parece que o SSL não é o problema depois de tudo ...

UPDATE 2 : É possível que isso seja algum tipo de problema de rede, porque eu não sou capaz de replicar isso usando ab em um servidor no mesmo datacenter, nem sou capaz de replicar isso usando ab no host local. No entanto ping o servidor em questão da minha estação de trabalho mostra 0% de perda de pacotes ... Então, eu não tenho certeza de quais os passos a seguir.

UPDATE 3 : Caso isso ajude, se eu executar ab para benchmark em um túnel SSH, eu não tenho falhas ... então talvez seja um problema de rede em vez de um problema do apache ...

    
por Josh 27.01.2010 / 01:54

1 resposta

1

Quando você diz que funciona muito bem quando a solicitação é feita no mesmo datacenter ou quando você usa um túnel ssh, acho que poderia ser algum tipo de modelagem entre o seu site remoto no datacenter.
Como se icmp e ssh (e outros) fossem mais priorizados que o http. Portanto, se a WAN se tornar sobrecarregada, o roteador poderá reduzir o tráfego HTTP. Geralmente, o SSH é priorizado porque precisa de alta interatividade, enquanto o FTP tem menos prioridade do que a transferência de arquivos.
Pergunte ao seu time de rede se existe algum Shaping ou QOS no lugar.

Outra coisa me diz que o problema é que o tempo de conexão é de 356 a 2268. 356 é bastante lento, eu acho que quando o túnel com SSH é menor que isso. e uma diferença tão alta entre min et max me diz que alguns pacotes provavelmente são dropados (devido ao QOS / Shaping) e retransmissão é necessária (então o tempo de conexão é mais lento)

    
por 27.01.2010 / 10:11