Skript beenden vor Gateway-Timeout

[weltvolk]

Die Direktive 'max_execution_time' ist auf 30 sec eingestellt, so dass größere Anfragen des Skriptes zu einem 504-Gateway-Timeout führen. Die Direktive soll nicht erhöht werden. Gibt es eine Möglichkeit, das Skript nach einer bestimmten Zeit, z. B. 25 sec, von selbst abzubrechen, um dem Timeout zuvorzukommen? Die Anfragen laufen nach der Initialisierung weiter und können auch mehrere Stunden dauern (Dateiübertragung mit cURL).

[onemorenerd]

register_tick_function()

[weltvolk]

Ein Hinweis, der mich zu sleep() geführt hat. Werde einmal Folgendes ausprobieren:

// Wenn Skript laenger als 25 sec kein Signal empfaengt, kann es 25 sec schlafen
if (sleep(25)) {
  echo "Anfrage wurde initialisiert und wird ohne weitere Rückmeldung des Servers verarbeitet";
} 

Mal sehen, ob das funktioniert ...

[onemorenerd]

Nee, das wird nicht funktionieren. Nicht so wie du denkst. Aber finde es ruhig selbst heraus.

[weltvolk]

Bin gerade dabei. Das Problem bei Ticks ist, dass sie bald veraltet sein werden und schon jetzt nicht auf allen Servern verwendet werden sollten.

[onemorenerd]

Was willst du denn eigentlich 5 Sekunden vorm Zeitlimit machen? Kann man das auch dann noch ausführen, wenn das Limit erreicht ist (register_shutdown_function)? Ansonsten sehe ich keine andere Möglichkeit als mit Ticks zu arbeiten. Alles andere würde eine kontrollierende Instanz außerhalb des eigentlichen Scripts erfordern.

[weltvolk]

Wenn die Anfrage einmal gestartet wurde, läuft sie, da kann man sogar das Skript löschen. Es soll nur vermieden werden, dass die Programmoberfläche durch 504 weggeblendet wird. Meinetwegen kann das Skript/die Programmoberfläche auch einfach angezeigt bleiben, ohne dass eine Meldung kommt. Hauptsache, die 504-Fehlermeldung wird vermieden.

[AmicaNoctis]

Hallo,

ich versteh' da was nicht ganz:

Die Anfragen laufen nach der Initialisierung weiter und können auch mehrere Stunden dauern (Dateiübertragung mit cURL).

Wie kann das denn sein, bzw. woher weißt du das? Wenn die max_execution_time auf 30 steht, bricht das Skript nach 30 Sekunden ab. Da läuft nichts weiter.

Ansonsten kann man bei Langlaufskripten die Kommunikation zum Client schon vorher beenden, wenn man Output Buffering nutzt, die Buffergröße als Content-Length-Header setzt, den Connection-Header auf close setzt und den Buffer schreibt. Für den Client ist die Anfrage dann beendet und dein Skript kann (im Rahmen der max_execution_time) dann noch sonst wie lange irgendwelche Daten schaufeln.

Gruß,

Anja

[weltvolk]

Wenn das Skript eine große Datei übertragen soll oder ein Rootverzeichnis als Backup, dauert dies zum Beispiel bei Lycos mehrere Stunden (gedrosselter Server), bis alle Daten angekommen sind. Das Skript ist dann schon lange nicht mehr an diesem Vorgang beteiligt. Das mit den Headern habe ich wiederum nicht verstanden ...

[AmicaNoctis]

Wer ist denn dann aber an dem Vorgang beteiligt? Ein externes Backuptool, ein Shellskript, ...? Jedenfalls klingt es irgendwie nicht nach dem typischen Browser-sendet-Anfrage-PHP-Skript-bearbeitet-sie-und-schickt-Daten-zurück-Schema.

[weltvolk]

Wie gesagt läuft es über cURL, bei Verzeichnissen innerhalb einer rekursiven Funktion.

[AmicaNoctis]

Das hilft mir immer noch nicht viel weiter.

Läuft dein Skript per Aufruf von einem Browser oder wird PHP z. B. von einem serverseitigen Cron-Job aus aufgerufen?

Wer erzeugt den 504-Fehler? Dein PHP-Skript, weil du das so wolltest oder die Seite die du mit cURL ansprichst oder irgend ein anderes Tool? Ich frage, weil PHP normalerweise bei einem Timeout lediglich eine Warnung erzeugt, aber keinen HTTP-Fehlerstatus.

Was meinst du mit "Programmoberfläche"? Die Webseite im Browser oder arbeitest du gar mit PHPGTK?

Wir kennen dein System nicht und mit den spärlichen Informationen ist es nicht machbar, dir zu helfen.

Gruß,

Anja

[weltvolk]

Ob die spärlichen Informationen auch bei Vervollständigung dir weiterhelfen, stelle ich hiermit als fraglich in den Raum. Ich sehe schon, dass es für mein klar formuliertes und eindeutiges Problem keine schnelle Lösung gibt.

[wahsaga]

Nein, wenn du nicht bereit bist, Rückfragen zu beantworten, dann gibt es nicht mal mehr etwas zu diskutieren.