SteelWheel
New member
Guten Morgen,
ich hab es gestern wieder geschafft, ein Stück aus meiner Tastatur heraus zu beißen. Denn wenn PHP mit "Out of Memory" und seinem "allocated"-Bytes Hinweis nach zirka 40 Sekunden Laufzeit in mein Browserfenster schreibt, dann schmeckt so ein Stück hochgezüchtetes Plastik sehr deliziös; erklärt aber auch den Tastaturbedarf per Jahr.
Also, das auslösende Script ist mehr als zehn Jahre alt und prozedural - ein wenig OOP schwingt mit (weil das schon Teile sind, die eben anders gebaut wurden). Es ist auf Linux wie auch Windows problematisch. In beiden Fällen steht das memory_limit auf 4095 (weil ich irgendwo gelesen hatte, dass 4096 nicht gehen würden - PHP 5.6 btw.)
Ich habe gestern noch Hände ringend nach Optimierungsmöglichkeiten gesucht, aber mir gehen die Ideen aus. So sind jetzt auch Sachen bspw. enthalten wie vorzeitig unset() bei bspw. Arrays.
Das Script funktioniert eigentlich nach einem reinen Include()-Prinzip: Die Hauptdatei mit zirka 1.300 Zeilen wird angestoßen und dann werden noch zirka 20 andere Dateien reingeholt, die ihrerseits wieder mächtig Zeilen haben. Es gibt leider nicht zu unterschätzende Abhängigkeiten (was bspw. direkt am Anfang zur Verfügung steht, muss am Ende auch noch da sein - darf nicht verworfen werden; den Teil vom Ende vorziehen geht aber nicht, weil wieder Bedingungen zuvor nötig usw.). Müsste ich das Script neu schreiben, benötige ich zirka zwei Tage - dann wäre es zwar total auf OOP, aber: Reicht das?
Ich habe am Datenvolumen noch gedreht - da kommt wirklich Kram aus der Datenbank (2 GB - aber nicht alles wird benötigt). Allerdings bekomme ich die Zahl auch nicht geringer bzgl. "allocated" (kein Erfolg mit den Maßnahmen ersichtlich oder noch viel zu weit weg).
Mir ist klar, dass ich mein prozedurales Zeug mit den includes() echt in die Tonne drücken muss (es ist schon sooo alt, lief beim letzten Einsatz vor drei Monaten auf der Linuxkiste aber noch).
Wie wäre es mit Multi-Threading?
Die CPU Last liegt auf Linux bei 99 % auf einem Kern; Windows weiß ich jetzt gerade nicht mehr.
Mmmmhm ... mein Problem ist also: Lohnt sich der Aufwand in Richtung OOP? Wenn der sich nämlich jetzt schon so vollsaugt, warum sollte er das später nicht mehr machen? Das Datenvolumen ändert sich nicht - kann schlecht auf eine AS/400 ausweichen.
Wenn das ein OOP wäre, würde ich womöglich meine "Abhängigkeiten" natürlich weiterhin brauchen - diese aber anders "aufbewahren". Vielleicht doch lieber temporäre Tables? Externe, temporäre eigene Dateien?
Mir fehlt hier ein wenig "best practise", da ich so einen Fall noch nie hatte - wer jongliert also von euch mit großen Datenmengen und kann mir da einen Kniff vorschlagen, bevor ich mein Script umschreibe?!
Das wäre super - vielen Dank allen Wortmeldern.
Beste Grüße
ich hab es gestern wieder geschafft, ein Stück aus meiner Tastatur heraus zu beißen. Denn wenn PHP mit "Out of Memory" und seinem "allocated"-Bytes Hinweis nach zirka 40 Sekunden Laufzeit in mein Browserfenster schreibt, dann schmeckt so ein Stück hochgezüchtetes Plastik sehr deliziös; erklärt aber auch den Tastaturbedarf per Jahr.
Also, das auslösende Script ist mehr als zehn Jahre alt und prozedural - ein wenig OOP schwingt mit (weil das schon Teile sind, die eben anders gebaut wurden). Es ist auf Linux wie auch Windows problematisch. In beiden Fällen steht das memory_limit auf 4095 (weil ich irgendwo gelesen hatte, dass 4096 nicht gehen würden - PHP 5.6 btw.)
Ich habe gestern noch Hände ringend nach Optimierungsmöglichkeiten gesucht, aber mir gehen die Ideen aus. So sind jetzt auch Sachen bspw. enthalten wie vorzeitig unset() bei bspw. Arrays.
Das Script funktioniert eigentlich nach einem reinen Include()-Prinzip: Die Hauptdatei mit zirka 1.300 Zeilen wird angestoßen und dann werden noch zirka 20 andere Dateien reingeholt, die ihrerseits wieder mächtig Zeilen haben. Es gibt leider nicht zu unterschätzende Abhängigkeiten (was bspw. direkt am Anfang zur Verfügung steht, muss am Ende auch noch da sein - darf nicht verworfen werden; den Teil vom Ende vorziehen geht aber nicht, weil wieder Bedingungen zuvor nötig usw.). Müsste ich das Script neu schreiben, benötige ich zirka zwei Tage - dann wäre es zwar total auf OOP, aber: Reicht das?
Ich habe am Datenvolumen noch gedreht - da kommt wirklich Kram aus der Datenbank (2 GB - aber nicht alles wird benötigt). Allerdings bekomme ich die Zahl auch nicht geringer bzgl. "allocated" (kein Erfolg mit den Maßnahmen ersichtlich oder noch viel zu weit weg).
Mir ist klar, dass ich mein prozedurales Zeug mit den includes() echt in die Tonne drücken muss (es ist schon sooo alt, lief beim letzten Einsatz vor drei Monaten auf der Linuxkiste aber noch).
Wie wäre es mit Multi-Threading?
Die CPU Last liegt auf Linux bei 99 % auf einem Kern; Windows weiß ich jetzt gerade nicht mehr.Mmmmhm ... mein Problem ist also: Lohnt sich der Aufwand in Richtung OOP? Wenn der sich nämlich jetzt schon so vollsaugt, warum sollte er das später nicht mehr machen? Das Datenvolumen ändert sich nicht - kann schlecht auf eine AS/400 ausweichen.
Wenn das ein OOP wäre, würde ich womöglich meine "Abhängigkeiten" natürlich weiterhin brauchen - diese aber anders "aufbewahren". Vielleicht doch lieber temporäre Tables? Externe, temporäre eigene Dateien?
Mir fehlt hier ein wenig "best practise", da ich so einen Fall noch nie hatte - wer jongliert also von euch mit großen Datenmengen und kann mir da einen Kniff vorschlagen, bevor ich mein Script umschreibe?!
Das wäre super - vielen Dank allen Wortmeldern.
Beste Grüße