☰

Solución de problemas de conexiones fallidas de Apache

tag-icon • tag-icon apache-2.2 ssl connection
Solución de problemas de conexiones fallidas de Apache

Estoy intentando solucionar algunos fallos de conexión intermitentes y extraños con Apache. Noté el problema cuando los usuarios se quejaron de que partes de la aplicación web que alojamos no funcionaban. La depuración reveló que las solicitudes AJAX no devolvían los datos XML o JSON que esperaba la aplicación JavaScript. La aplicación se entrega a través de SSL.

Cuando me probé, vi fallas intermitentes y Firebug mostró que la longitud de la respuesta era cero o que la conexión parecía fallar por completo. Los registros de aplicaciones en el servidor no mostraron problemas, incluso cuando Firebug informó que la respuesta estaba vacía: el registro de aplicaciones en el servidor mostró que se habían enviado datos.

Por una corazonada, encendí apachebench ( ab) y me sorprendió encontrar algunas fallas de conexión:

[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)

Estas solicitudes eran para una página HTML estática, por lo que mi aplicación PHP no parece ser el problema aquí. La ejecución de las pruebas a través de HTTP normal (no SSL) no produjo ningún error . No sé qué podría estar pasando... ni siquiera estoy seguro de cómo solucionar el problema desde aquí. Con mucho gusto publicaré la configuración de httpd.conf, solo déjame saber qué partes ayudarían. El servidor es Apache/2.2.3 (CentOS), con mpm_worker y mod_fastcgi...

ACTUALIZAR: Acabo de que mi primera prueba ab devolviera 2 fallas de conexión a través de HTTP normal, para la misma página HTML. Entonces parece que SSL no es el problema después de todo...

ACTUALIZACIÓN 2: Es posible que se trate de algún tipo de problema de red, porque no puedo replicar esto usando aben un servidor en el mismo centro de datos, ni puedo replicar esto usando aben localhost. Sin embargo, hacer ping al servidor en cuestión desde mi estación de trabajo muestra 0% de pérdida de paquetes... Así que no estoy seguro de qué pasos seguir a continuación.

ACTUALIZACIÓN 3: En caso de que ayude, si ejecuto abla evaluación comparativa a través de un túnel SSH, no obtengo fallas... así que tal vez esto sea un problema de red en lugar de un problema de Apache...

Respuesta1

Cuando dice que funciona muy bien cuando las solicitudes se realizan en el mismo centro de datos o cuando usa un túnel ssh, creo que podría haber algún tipo de configuración entre su sitio remoto en el centro de datos.
Como si icmp y ssh (y otros) tuvieran más prioridad que http. Entonces, si la WAN se sobrecarga, el enrutador puede reducir el tráfico http. Generalmente se prioriza SSH porque necesita una alta interactividad, mientras que FTP tiene menos prioridad debido a la transferencia de archivos.
Pregunte a su equipo de red si existe algún Shaping o QOS.

Otra cosa me dice que el problema podría ser que el tiempo de conexión es de 356 a 2268. 356 es bastante lento, supongo que cuando se hace un túnel con SSH es menos que eso. y una diferencia tan alta entre min y max me dice que es probable que algunos paquetes se eliminen (debido a QOS/Shaping) y se necesite retransmitir (por lo que el tiempo de conexión es más lento)

información relacionada