gelöscht

[Bleistift]

mit fopen()?
Aber du solltest aufpassen, dass es nicht endlos wird

[Flor1an]

Warum möchtest du dass sich ein Cronjob nochmal aufruft? Dadurch wird es doch zu einer Endlosschleife!

[Jann Hendrik]

das hat doch mit cronjobs nichts zu tun...


mach bei der aufgerufenen Seite einfach keine Ausgabe, und dann kannst du header() nutzen.

[Flor1an]

Also mir ist keine Lösung bewusst die das dann effektiv ausführt.

Das einzigste wäre eben wenn der User im Browser das Skript aufruft und dieses sich dann wiederholt öffnet!

[Basti]

Ich würde versuchen, zwei Eingänge für das Skript zu gestalten. Einen, der nur per Cronjob ansprechbar ist und einen, der über HTTP zugänglich ist. Wenn du nicht fertig wirst, dann speicherst du einen Hash auf dem Server und rufst das Skript mit kurzem Timeout und mit dem Hash als GET-Parameter via fsockopen() über den öffentlichen Eingang auf und so alt immer weiter bis du fertig bist. Wenn alles erledigt ist, löschst du den Hash und machst damit die Tür über HTTP wieder zu.

Basti

[dsxs]

Es gibt eine Möglichkeit.
Bei meinem Host (auch shared) reicht es, eine eigene php.ini mit max_execution_time = 0 zu definieren, resp. im Script selber mit ini_set() so einzustellen, oder es sollte ebenfalls möglich sein (falls die Funktion verfügbar ist), mit system() das Script neu aufzurufen und wieder die standardmässigen 30 Sekunden zur Verfügung zu haben... Das hast Du aber bestimmt schon ausprobiert.

Ansonsten frage einmal bei Daniel nach (daniel-schlichtholz.de), einem der beiden Macher des mysqlDumpers. Das Script arbeitet nach demselben Prinzip - es ruft sich selber unendlich oft erneut auf, und ermöglicht so das dumpen von riesigen MySQL DBs auch bei eingeschränkter Hosting Umgebung.

[robo47]

Zitat von dsxs

Ansonsten frage einmal bei Daniel nach (daniel-schlichtholz.de), einem der beiden Macher des mysqlDumpers. Das Script arbeitet nach demselben Prinzip - es ruft sich selber unendlich oft erneut auf, und ermöglicht so das dumpen von riesigen MySQL DBs auch bei eingeschränkter Hosting Umgebung.

wenn ich mich nicht irre, ist das aber ein dumpen / dumps einspielen über ein web-frontend (im Browser), wo man mit JS oder html-boardmitteln einfach weitergeleitet wird, das klappt bei nem Cronjob nicht und das ist mit sicherheit von hostern auch so gewollt!

[dsxs]

Zitat von robo47

wenn ich mich nicht irre, ist das aber ein dumpen / dumps einspielen über ein web-frontend (im Browser), wo man mit JS oder html-boardmitteln einfach weitergeleitet wird, das klappt bei nem Cronjob nicht und das ist mit sicherheit von hostern auch so gewollt!

Nee eben, das ists gerade: der mysql Dumper kann auch als Cron ausgeführt werden (Perl script), und auch da klappt die Umgehung des Timeouts wunderbar. Wies gemacht wird weiss ich wie gesagt nicht

[Jann Hendrik]

Zitat von Bruchpilot69

header-Befehle klappen aber nicht beim Cronjob

sry - dann habe ich auch mal wieder was gelernt...

Zitat von dsxs

Das Script arbeitet nach demselben Prinzip - es ruft sich selber unendlich oft erneut auf, und ermöglicht so das dumpen von riesigen MySQL DBs auch bei eingeschränkter Hosting Umgebung.

per Browser: ja.
Aber für den Aufruf per cronjob nutzt das ein perl-Skript.

[Bleistift]

Ich kann mich auch irren, aber meistens hat man bei Perl keine max. Ausführungszeit... Du könntest also ein Perl-Script schreiben, welches dein PHP-Script immer wieder aufruft, bis dein Script fertig ist. Anstossen kannst du das Perl-File ja dann per Cronjob.

[dsxs]

Zitat von Bleistift

Ich kann mich auch irren, aber meistens hat man bei Perl keine max. Ausführungszeit... Du könntest also ein Perl-Script schreiben, welches dein PHP-Script immer wieder aufruft, bis dein Script fertig ist. Anstossen kannst du das Perl-File ja dann per Cronjob.

Stimmt, geht mittels Perl Script... Ich dachte, das hätte in etwa dieselben Einschränkungen, sorry

[Jann Hendrik]

eine uncoole Möglichkeit wäre eine Seite mit frames aufzubauen, wo du Stück für Stück kleine Bruchteile abarbeitest, wenn du das was du vorhast parallel abarbeiten kannst.

Wieviele Fenster dein frame haben muss kannst du berechnen, wenn du weißt, wieviel in einem Fenster abgearbeitet werden kann, ohne dass es zu einem Abbruch kommt und du weißt, wieviel du insgeammt arbeiten musst.



Eine andere Idee, die mir gerade kommt...
coppermine hat ein ähnliches Problem bei der Erzeugung von thumbnails. Dort wurde das so gelöst, dass man eine Seite sieht, wo Grafiken eingebunden werden, die in echt PHP-Skripte sind, welche die Bilder erzeugen.

Wenn du nun eine Seite mit 10 Bildern hast, die von PHP erzeugt werden müßen, wobei jedes PHP-Skript ersteinmal ein wenig arbeitet, dann kannst du damit die Zeit auch ein wenig drücken, weil die vom cronjob aufgerufene Seite ja nur auf die Bilder wartet.

[Bleistift]

Ein Cronjob lädt normalerweise weder Frames noch Bilder :/

[Basti]

Wo ist denn das Problem? Du kannst, wie von mir hier beschrieben, per CronJob doch einen HTTP-Request absetzen und das Skript dann dicht machen, ohne auf die Antwort zu warten. Damit kannst du das Skript immer wieder sich selbst aufrufen lassen. Musst halt nur sicherstellen, dass der Zugriff kontrolliert abläuft.

Basti

[Jann Hendrik]

hach Mist....


okay, dann bleibt dir neben dem perl-Skript auch noch die Möglichkeit einfach mal den support von all-inkl.com zu fragen. Die antworten idR schnell und hilfreich!
Ich habe jedenfalls fast immer gute Erfahrungen gemacht.

[robo47]

Um es auf den Punkt zu bringen, das Script braucht zu viel Performance, bei sowas sollte man sich dann halt irgendwann überlegen sich nen V-Server zuzulegen, da kann man sein PHP einstellen wie man will.

Ausserdem sollte man vieleicht auch an die anderen Leute die denken die bei Shared-Hosting mit auf der eigenen Kiste sind, weil wer würde sich nicht aufregen, wenn der Server den ganzen Tag andauern ausgelastet ist, weil jeder seine rechen-intensiven Cronjobs laufen lässt.

[Jann Hendrik]

gibt ja auch noch die Möglichkeit, dass das nicht den ganzen Tag läuft, sondern nur gelegentlich.

Aber generell hast du Recht - ist den anderen nicht fair, daher ist es ja auch nur ein shared-Server.

Ggf. mal den hoster, hier also all-inkl.com ansprechen, ob sie eine vertretbare Lösung vorschlagen können.