Resourcenhungrige Apache-Prozesse im Hintergrund laufen lassen

[abjetztneu]

Ich habe einen Apache laufen, der Webserver für mehrere Internetseiten ist. Nun soll dort zusätzlich mittels system(..)-Aufruf in einer php-Seite, die als http-cronjob regelmäßig aufgerufen wird, lokale, sehr rechenintensive Encodierungsprozesse gestartet werden.
Das Problem ist, dass jedes mal wenn das Encoding im Gange ist, die Webserveraktivität dadurch komplett blockiert wird, d.h. es werden keine anderen Webserveraktivitäten, wie Seiten ausliefern, etc. ausgeführt, solange der Encoding-Prozess nicht beendet ist.

Gibt es eine Möglichkeit, diese rechenintensiven Prozesse von den Webserveraktivitäten abzukoppeln (und evtl. auch aus der normalen Skript-Laufzeitbegrenzung auszunehmen?) bzw. die Priorität des Prozesses enorm zu "erniedrigen"?

Was ich bereits versucht habe, ist "nice" vor den encodierungsbefehl zu schreiben. Das hat jedoch die performance-blockade leider nicht beseitigt.

ich bin über jede Idee sehr dankbar!

Grüße,
Bernd

[petameta]

Welchen Nice-Wert hast Du denn benutzt ? Eigentlich sollte das klappen.

[klopskuchen]

> http-cronjob
Wasn dat?

Da der offensichtlich keine Interaktion benötigt (sonst wär es kein cronjob?), kannst du die Informationen die du aus der Serverumgebung brauchst in eine Datei schreiben lassen und ein richtiger Cronjob holt sich die wenn die Zeit ran ist.

Hier ein Auszug aus dem php.net-Manual:
"Die system() Funktionsaufrufe versuchen übrigens automatisch nach jeder Ausgabezeile den Ausgabebuffer des Webservers zu flushen, wenn PHP als Servermodul läuft"
Ziemlicher Müll also.
Da bist du wahrscheinlich mit einem cgi-script und dessen suexec() schneller und besser bedient. Oder wie oben beschrieben völlig trennen und Daten über eine Datei austauschen.


MfG, Klopskuchen

[abjetztneu]

Da bist du wahrscheinlich mit einem cgi-script und dessen suexec() schneller und besser bedient.

Mit cgi-scripts kenne ich mich leider gar nicht aus. Könnte es aber entsprechen auch eine Lösung sein, im php-script die Encodingaufrufe mittles exec(...) anstelle von system(...) aufzurufen?

> http-cronjob
Wasn dat?

ich meinte damit einen cronjob, der in bestimmten abständen eine .php datei, die auf dem webserver liegt als "normalen" Seitenaufruf anfordert. Hmm.. alernativ könnte ich die .php datei allerdings auch direkt per php befehl auf der kommandozeile aufrufen, hab ich nur noch nie probiert. Vielleicht ermöglicht das, dass der Prozess auch noch webserver-aktivitäten zulässt?

Welchen Nice-Wert hast Du denn benutzt ?

Ich hatte nichts angegeben. Laut manpage gilt dann der defaultwert 10. Ist das ok?

[klopskuchen]

Könnte es aber entsprechen auch eine Lösung sein, im php-script die Encodingaufrufe mittles exec(...) anstelle von system(...) aufzurufen?

Du kannst innerhalb der Funktionsaufrufe die Ausgabe umleiten. Bei system('while [ TRUE ]; do echo bla >/dev/null; done', $ret); startest du eine Endlosschleife, in der die Ausgabe nach /dev/null geschickt wird und so phps read() (und flush) entfällt, was den Anteil der serverseitigen Last ausmacht. Allerdings bekommt die Funktion dann gar keine Ausgabe mehr.
Bei einem cgi-script schreibst du dein Zeug einfach als normalen php-code in eine Datei, steckst sie ins Verzeichnis das in der httpd.conf als cgi-dir angegeben ist und startest das ganze wie gewohnt. Nur das du den Pfad relativ zum cgi-dir angibst. Dann wird mit fork() ein eigener Prozess gestartet, der sich bei Beendigung zurückmeldet.
Aber warum blockiert der Server? Du startest das script doch nur einmal, oder? Der Server erstellt sich selbst neue Kindsprozesse, wenn sie ihm auszugehen drohen.


MfG, Klopskuchen