Ich programmiere eine REST API mit Zend Framework .
Wenn Sie die URL mehrmals aufrufen (z. B. 1000 mal mit 1 Anfrage pro Sekunde), in etwa 0,2% Fällen statt 200 OK als Antwort bekomme ich < strong> 302 Found - also eine Weiterleitung auf eine andere Seite.
Hier ist die gesamte Serverantwort:
Also wird Zend zur Seite error 500 (interner Serverfehler) weitergeleitet. Die Frage ist warum - und ich kann es einfach nicht herausfinden ...
Die php-Seite, die aufgerufen wird, fügt eine Zeile in eine MySQL-Datenbank ein und gibt eine JSON-Zeichenfolge zurück - das ist alles.
Apache2 hat ungefähr 20 gleichzeitige Verbindungen geöffnet und die Serverlast ist & lt; & lt; 1, so dass ich wirklich nicht verstehe, warum die Anfragen Probleme verursachen.
Ich weiß, dass dies ein wirklich schwieriges Problem für die Ferndiagnose ist, aber gute Vermutungen und Empfehlungen, wie das zu lösen ist, sind mehr als willkommen! Danke.
Dies ist die Apache vhost Config wie von @chris angefordert:
%Vor%Wow - das war ein völlig unerwartetes Problem und wirklich schwer herauszufinden ...
@AdrianWorld hat mir geholfen, auf dem richtigen Weg zu sein. Im Zend ErrorController gab ich die Fehlermeldung aus und fand die folgende Ausnahme:
%Vor% Das ist scheinbar ein ziemlich häufiges Problem, wie beschrieben und gelöst hier .
Die Variable session.gc_probability wurde in 1 auf php.ini gesetzt, was bedeutet, dass der Garbage Collector eine 1% ige Wahrscheinlichkeit hat, das Verzeichnis /var/lib/php5 auszuführen und zu bereinigen, in dem die php-Sessions gespeichert sind. Anscheinend ist dieser Ordner nicht von www-data beschreibbar, was zu dem erwähnten Fehler führt und die Zend-Ausnahme auslöst.
Da session.gc_probability nur eine Wahrscheinlichkeit angibt, ist der Fehler zufällig aufgetreten, was das Debugging ziemlich schwierig macht.
Wie auch immer, ich bin froh, dass es gelöst ist - danke für alle Hinweise und Vermutungen:)
Das sieht ziemlich einfach und direkt für mich aus. Dies ist eine Umleitung von 302, und ich kann mir nichts in ZF vorstellen, das von selbst weiterleitet; vor allem nicht auf eine 500 Fehlerseite. Ein 500 Fehler (interner Serverfehler) muss immer einen 500 Fehler zurückgeben und sollte niemals 302 Redirect sein. Sie sind hier also glücklich, weil eine Fehlerbehandlung in Ihrer RETS-API erforderlich ist , die irgendwo eine Umleitung verursacht (anstelle einer normalen Fehlerseite).
Suchen Sie in Ihrem Code nach Weiterleitungen. Es könnte mit dem ZF-Redirector-Helfer (in einem Controller) oder manuell (überall) mit Header () und exit () erfolgen. Wenn Sie die Umleitung gefunden haben, zeigen Sie entweder show (exit) mit einem debug_backtrace an oder legen Sie das in eine Protokolldatei ab. Und reparieren Sie auch den Rückgabecode oder die Art, wie der Fehler behandelt wird.
Beachten Sie, dass Apache, wenn Sie ein ErrorDocument angeben, das auf eine Remote-URL verweist (also irgendetwas mit einer Methode wie http vor sich), eine Weiterleitung an den Client sendet, um ihm mitzuteilen, wo das Dokument selbst zu finden ist wenn sich das Dokument auf dem gleichen Server befindet.
Ich nehme an, dass Sie die Direktive ErrorDocument in Ihrer Apache HTTP-Server-Konfiguration verwenden, die dann für 500 Fehler konfiguriert wird.
500 Fehler können von PHP selbst ausgelöst werden. Um herauszufinden, was passiert, müssen Sie sowohl in das Server-Fehlerprotokoll als auch in das PHP-Fehlerprotokoll schauen (und natürlich PHP-Fehlerprotokollierung dafür aktivieren).
Oder wie ich es schreibe:
A 500 Interner Serverfehler ist immer eine Einladung, sich das Fehlerprotokoll des Servers anzusehen. Es enthält mehr Informationen. Da dies PHP ist, ist es auch sehr wahrscheinlich, dass es auf einen Fatalen Fehler in PHP zurückzuführen ist, so dass die PHP-Fehlerprotokollierung aktiviert ist und ein Blick in das PHP-Fehlerprotokoll ebenfalls sehr nützlich ist. Weitere Informationen zum 500 Internal Server Error
Ohne weitere Details über Ihre Anwendung ist es ziemlich schwer zu erraten. Meine Vermutung ist, dass einer Ihrer Dienste (höchstwahrscheinlich eine Datenbank) unter erhöhtem Verkehr und I / O langsamer wird. Daher kann es bei einigen PHP-Verbindungen zu einem Timeout kommen. Dies führt zu einem Anwendungsfehler und leitet auf die Fehlerseite um.
Hängt davon ab, wie gut Ihre Anwendung bei der Protokollierung interner Probleme in logs/application.log aussieht, aber standardmäßig ist es nicht sehr gut, Dinge zu protokollieren.
Tags und Links php mysql api apache2 zend-framework