Reaktion auf Laufzeitüberschreitung

[ecomeback]

Hallo!

Derzeit macht mir eine Applikation sorgen, da diese sich immer mehr in Richtung Laufzeitüberscheitung entwickelt. Natürlich ist die erste Maßnahme eine oder sogar mehrere Codeoptimierungen, was zwar Erfolg zeigte, die Datenmenge aber so schnell wächst, dass mich das Problem sehr schnell einholt.
Kern des Problems ist eine regelmäßige Überprüfung aller Datensätze auf neue Bedingungen, die täglich eingespielt werden. So müssen dann relativ viele Datensätze gegen eben diese Bedingungen geprüft werden.
Zum einen wird dazu ein Cronjob ausgeführt und zum anderen wird nach bestimmten Benutzeraktionen der Prozess der Prüfung angestoßen, da die Überprüfung nach Benutzerinteraktion relativ zeitnah erfolgen muss.

Trotz Optimierung und vielen Versuchen die Laufzeit zu drücken bin ich immer ratloser, wie man diesem Problem sinnvoll begegnen kann. Derzeit sind durchschnittliche Laufzeiten um die 65 Sekunden noch unproblematisch, aber dennoch kritisch. Wenn die Datenmenge weiter so skaliert, ist ein Ende relativ schnell abzusehen. Ich möchte keine Lösungen, die es möglich machen, Endlosschleifen laufen zu lassen.

Wie kann man diesem Problem begegnen? Teilung des Prozesses in kleinere Arbeitspakete? Wie lässt sich so etwas abbilden?
Und sehr spannend für mich: Wie kann man während der Laufzeit auf eine Überschreitung der Laufzeit reagieren? Kann man so etwas überhaupt auf der PHP Ebene abfangen und rechtzeitig vom dem Abbruch darauf reagieren?

Viele Grüße
ec

[akretschmer]

klingt, als wären Datenbankabfragen Dein Problem. Falls ich richtig liege: was sagt denn EXPLAIN ANALYSE zu diesen Abfragen?

[protestix]

Viel zu allgemein um da überhaupt eine Aussage treffen zu können.
Du musst deinen Flaschenhals finden, also die Ursache und nicht an den Symptomen arbeiten.

Mit einer längeren Scriptlaufzeit ist es hier nicht getan.

Ein SQL-Dump wäre schon mal der erste Schritt mit einigen Beispieldatensätzen.

Dann, wie viele Datensätze sind es derzeit und wie viele kommen täglich hinzu.

Dann das Script an sich womit du die Abfragen aufrufst.

Etwas Informationen zur Umgebung, RAM, eingesetzte Hardware etc. sind auch immer gut, wenn es um Optimierungen geht.

Wenn du das alles präsentierst, kann man darüber reden wo man ansetzen kann.

[michga93]

Was mir persönlich weitergeholfen hat, war der Dienst blackfire.io
Da wahrscheinlich einiges an Code hinter deiner Applikation steckt, wird es schwierig sein, hier im Forum die Lösung zu finden. Mit blackfire wird dein Code hinter dem Aufruf komplett analysiert, sodass du Flaschenhälse finden und beheben kannst.

@Moderation:
ich hoffe, dass der Hinweis erlaubt ist und nicht als Schleichwerbung angesehen wird. Falls doch bitte Löschen

[lstegelitz]

Kern des Problems ist eine regelmäßige Überprüfung aller Datensätze auf neue Bedingungen, die täglich eingespielt werden.

Immer .. Alle.. ?

Da kannst du noch so performate Queries schreiben, wenn die Datenmenge immer weiter steigt wird das zwangsläufig immer länger dauern.

Möglichkeiten für die Skalierung wäre, mehrere parallele Prozeße zu starten, wobei jeder Prozeß nur einen (konstanten) Teil der Daten verarbeitet. Damit kannst du bei steigender Datenmenge weitere Server zuschalten um die Laufzeit mehr oder weniger konstant zu halten.

[erc]

1. Schau dir an was am meisten Zeit kostet. In der Regel hast du in PHP selten Algorithmen die viel CPU Zeit kosten. Der Flaschenhals ist typischerweise der Schnittpunkt zwischen PHP und Datenbank. Schau wie du Queries zusammenfassen kannst, schau wie du Queries vermeiden kannst, schau das du nicht sinnlos schreibst (updates die nix ändern)

2. Such ein intelligenteren Ansatz als die Holzhammer-Methode. Nur weil sich eine handvoll Werte ändert, muss dadurch alles neu berechnet werden?

Wie kann man während der Laufzeit auf eine Überschreitung der Laufzeit reagieren? Kann man so etwas überhaupt auf der PHP Ebene abfangen und rechtzeitig vom dem Abbruch darauf reagieren?

Ein max_execution_time Fehler kannst du nicht abfangen. Du kannst mit time() die Laufzeit selbst prüfen und ggf. abbrechen. Das funktioniert aber nur solange, wie das PHP Script nicht durch externe Ressourcen ins Timeout läuft (z.B. warten auf ein Query).

[jspit]

PHP-Manual

Hinweis:
Die set_time_limit()-Funktion und die max_execution_time Konfigurationsdirektive beschränken nur die Ausführungszeit des Skripts selbst. Zeit die für Aktivitäten außerhalb des Skripts aufgebracht wird wie z.B. die Ausführung von Systemaufrufen mit system(), Streamoperationen, Datenbankabfragen usw. werden nicht in die Berechnung der Ausführungszeit mit einbezogen.

Das versehe ich so, das ein PHP Script eben nicht so leicht durch externe Resourcen in ein Timeout laufen kann. Im Klartext kann ein Script mit einer max_execution_time von 90 Sekunden auch schon mal erheblich länger laufen ohne das es zu einen Fehler kommt. Das macht eine Abschätzung wie viel Zeit ein Script noch hat m.E. fast unmöglich.

[erc]

Die Windows Binaries verhalten sich definitv anders.

[jspit]

Stimmt, ist mir noch gar nicht aufgefallen.
Schnelltest:

set_time_limit(10);
debug::write('start');
sleep(15);
debug::write('end'); 

Unter Window:
Fatal error: Maximum execution time of 10 seconds exceeded in ..

Unter Linux

[23.01.2018 09:10:27,096][+15.000 s](387k/411k) Debug::write ..    
0
       string(3) ASCII
      "end"

Die Frage ist nun, welches System nutzt ecomeback ?