☰

Fehlerbehebung bei fehlgeschlagenen Apache-Verbindungen

tag-icon • tag-icon apache-2.2 ssl connection
Fehlerbehebung bei fehlgeschlagenen Apache-Verbindungen

Ich versuche, einige merkwürdige, zeitweilige Verbindungsfehler mit Apache zu beheben. Ich bemerkte das Problem, als Benutzer sich beschwerten, dass Teile der von uns gehosteten Webanwendung nicht funktionierten. Beim Debuggen stellte sich heraus, dass AJAX-Anfragen nicht die XML- oder JSON-Daten zurückgaben, die die JavaScript-Anwendung erwartete. Die Anwendung wird über SSL bereitgestellt.

Bei meinen eigenen Tests traten zeitweise Fehler auf und Firebug zeigte an, dass entweder die Antwortlänge null war oder die Verbindung anscheinend vollständig fehlschlug. Die Anwendungsprotokolle auf dem Server zeigten keine Probleme, auch nicht, als Firebug meldete, dass die Antwort leer war – das Anwendungsprotokoll auf dem Server zeigte, dass Daten gesendet worden waren.

Ich hatte eine Ahnung und startete apachebench ( ab) und stellte zu meiner Überraschung einige Verbindungsfehler fest:

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

Diese Anfragen betrafen eine statische HTML-Seite, meine PHP-Anwendung scheint also nicht das Problem zu sein. Die Tests über normales HTTP (ohne SSL) führten zu keinerlei Fehlern . Ich weiß nicht, was los sein könnte … ich bin mir nicht einmal sicher, wie ich das Problem von hier aus beheben soll. Ich werde die httpd.conf-Konfiguration gerne posten, lassen Sie mich einfach wissen, welche Teile hilfreich wären. Der Server ist Apache/2.2.3 (CentOS), mit mpm_worker und mod_fastcgi …

AKTUALISIEREN: Mein erster AB-Test hat gerade 2 Verbindungsfehler über normales HTTP für dieselbe HTML-Seite ergeben. Es sieht also so aus, als ob SSL doch nicht das Problem ist ...

AKTUALISIERUNG 2: Möglicherweise handelt es sich um eine Art Netzwerkproblem, da ich dies weder abauf einem Server im selben Rechenzentrum noch abauf dem lokalen Host replizieren kann. Wenn ich den betreffenden Server jedoch von meiner Workstation aus anpinge, wird ein Paketverlust von 0 % angezeigt. Daher bin ich mir nicht sicher, welche Schritte ich als Nächstes unternehmen soll.

AKTUALISIERUNG 3: Falls es hilft: Wenn ich abden Benchmark über einen SSH-Tunnel ausführe, treten keine Fehler auf. Vielleicht handelt es sich also eher um ein Netzwerkproblem als um ein Apache-Problem.

Antwort1

Wenn Sie sagen, dass es großartig funktioniert, wenn Anfragen im selben Rechenzentrum gestellt werden oder wenn Sie einen SSH-Tunnel verwenden, denke ich, dass es eine Art Shaping zwischen Ihrer Remote-Site im Rechenzentrum sein könnte.
Beispielsweise wenn ICMP und SSH (und andere) höher priorisiert sind als HTTP. Wenn also das WAN überlastet wird, kann der Router den HTTP-Verkehr unterbrechen. Im Allgemeinen wird SSH priorisiert, weil es eine hohe Interaktivität erfordert, während FTP weniger priorisiert ist, da es sich um Dateiübertragungen handelt.
Fragen Sie Ihr Netzwerkteam, ob Shaping oder QOS vorhanden sind.

Eine weitere Sache sagt mir, dass das Problem darin liegen könnte, dass die Verbindungszeit zwischen 356 und 2268 liegt. 356 ist ziemlich langsam, ich vermute, dass es beim Tunneln mit SSH weniger ist. Und ein so großer Unterschied zwischen Minimum und Maximum sagt mir, dass einige Pakete wahrscheinlich verloren gegangen sind (aufgrund von QOS/Shaping) und eine erneute Übertragung erforderlich ist (deshalb ist die Verbindungszeit langsamer).

verwandte Informationen