2010-11-29 17 views
50

Gibt es einen guten Grund, die PHP-Konfigurationsvariable max_execution_time nicht auf 0 zu setzen?Ist ini_set ('max_execution_time', 0) eine schlechte Idee?

Ein Mitarbeiter vor kurzem in einer Änderung in eine Datei überprüft, die hinzugefügt:

ini_set('max_execution_time', 0); 

Der Standardwert war zu niedrig für eine Seite, die eine komplexe Verarbeitung tat, bevor die Ausgabe an den Benutzer zurück.

Das Handbuch erklärt, dass der Hauptzweck der Einstellung ist:

verhindern, dass Skripte den Server von binden schlecht geschrieben.

Aber geht auch es weiter:

Ihr Webserver andere Timeout Konfigurationen haben kann, die auch PHP Ausführung unterbrechen kann. Apache hat eine Timeout Direktive und IIS hat eine CGI-Timeout-Funktion. Beide sind standardmäßig auf 300 Sekunden eingestellt. Einzelheiten finden Sie in der Dokumentation zum Webserver.

Wir laufen unter Apache, so dass Timeout Einstellung gilt. Gibt es einen Grund, max_execution_time global nicht auf Null zu setzen? Ich bin hauptsächlich neugierig, ob es Vorteile gibt, die ich übersehen habe, wenn nicht auf Null gesetzt wird.

+0

in PHP 7, es ist ini_set ('max_execution_time', '0') dosiert werden kann; (0 ist eine Zeichenkette, sonst erhalten Sie einen TypeError). Und ja, das ist eine gute Idee in dev, wenn Sie schwere Berechnungsskripte ausführen müssen. – ling

Antwort

56

Auf das Risiko, Sie zu irritieren;

Sie stellen die falsche Frage. Sie brauchen keinen Grund, NICHT von den Vorgaben abzuweichen, sondern umgekehrt. Sie brauchen einen Grund dafür. Timeouts sind bei der Ausführung eines Webservers unbedingt erforderlich, und diese Einstellung ohne Angabe von Gründen zu deaktivieren, widerspricht grundsätzlich der guten Praxis, selbst wenn sie auf einem Webserver ausgeführt wird, der eine eigene Timeout-Anweisung besitzt.

Nun, wie für die echte Antwort; wahrscheinlich ist es in diesem speziellen Fall überhaupt nicht wichtig, aber es ist eine schlechte Übung, sich an ein separates System zu setzen. Was passiert, wenn das Skript später auf einem anderen Server mit einem anderen Timeout ausgeführt wird? Wenn Sie sicher sagen können, dass es nie passieren wird, ist es gut, aber gute Praxis geht weitgehend darum, scheinbar unwahrscheinliche Ereignisse zu berücksichtigen und nicht unnötig die Einstellungen und Funktionen von völlig verschiedenen Systemen miteinander zu verbinden. Die Entlassung solcher Prinzipien ist für viele sinnlose Inkompatibilitäten in der Softwarewelt verantwortlich. Fast jedes Mal sind sie unvorhergesehen.

Was ist, wenn der Webserver später so eingestellt ist, dass er eine andere Laufzeitumgebung ausführt, die nur die Timeout-Einstellung vom Webserver übernimmt? Nehmen wir zum Beispiel an, dass Sie später ein 15 Jahre altes CGI-Programm benötigen, das in C++ von jemandem geschrieben wurde, der auf einen anderen Kontinent gezogen ist, der keine Zeitüberschreitung außer dem des Web-Servers hat. Das kann dazu führen, dass das Zeitlimit geändert werden muss und weil PHP sich sinnlos auf das Zeitlimit des Webservers anstatt auf sein eigenes verlässt, was Probleme für das PHP-Skript verursachen kann. Oder andersherum, dass Sie aus irgendeinem Grund eine geringere Zeitüberschreitung beim Webserver benötigen, aber PHP muss es immer noch höher haben.

Es ist einfach keine gute Idee, die PHP-Funktionalität mit dem Webserver zu verbinden, da der Webserver und PHP für verschiedene Rollen verantwortlich sind und so funktional getrennt wie möglich gehalten werden sollten.Wenn die PHP-Seite mehr Verarbeitungszeit benötigt, sollte es eine Einstellung in PHP sein, einfach weil es für PHP relevant ist, nicht unbedingt alles andere auf dem Webserver.

Kurz gesagt, es ist nur unnötig die Angelegenheit zu verbinden, wenn es nicht nötig ist.

Last but not least, 'stillstanding' hat Recht; Sie sollten zumindest lieber set_time_limit() als ini_set() verwenden.

Hoffe, das war nicht zu bevormundend und irritierend. Wie ich schon sagte, ist es unter deinen spezifischen Umständen wahrscheinlich in Ordnung, aber es ist eine gute Übung, nicht davon auszugehen, dass deine Umstände die Eine Wahre Gegebenheit sind. Das ist alles. :)

+0

Ich versuche hauptsächlich, die Gründe für den Fehler zu verstehen. Nur weil es ein Standard ist, macht es es nicht gut. Die Einstellung 'max_execution_time' ist immer noch die gleiche wie bei einem "Endlos-Loop-Detektor". Und die PHP-Implementierung (standardmäßig 0 unter 'cli', sonst 30) scheint dem Argument zu widersprechen, die "Einstellungen und Funktionen völlig unterschiedlicher Systeme unnötig miteinander zu verknüpfen". Nichtsdestoweniger haben Sie eine gut geschriebene, prinzipielle Antwort mit guten Beispielen geliefert. Vielen Dank. – benizi

+0

Nun, in einer Befehlszeilenumgebung wird man nie mit der Umgebung fertig (daher die Bedeutung der POSIX-Konformität), so dass es nicht genau vergleichbar ist. Aber noch dazu ist CLI PHP relativ neu; PHP war nicht als CLI-Umgebung gedacht bis Version 4.5 oder sogar 5, glaube ich. – Teekin

+1

Wer steht still und wo kann ich ihn finden? –

11

Grund ist, einen anderen Wert als Null zu haben. Allgemeine Praxis um es kurz zu haben global und lange für lange Skripte wie Parser, Raupen, Dumper arbeiten, Export & Import-Skripte usw.

  1. Sie können Speicher-Server, korrupte Arbeit anderer Leute halt Skript raubend, ohne auch nur es zu wissen.
  2. Sie werden keine Fehler sehen wo etwas, sagen wir, Endlosschleife passiert ist, und es wird schwerer zu diagnostizieren sein.
  3. solcher Ort leicht durch einzelne Benutzer beim Anfordern Seiten mit langer Ausführungszeit
Verwandte Themen