Hallo Martin,
prinzipiell hast Du ja recht, aber exec hat den Nachteil, dass es auf das Ende des gerufenen Programms wartet und damit für asynchrone Worker nicht geeignet ist.
Just learned: Einen asynchronen Prozess kriegst Du mit proc_open hin (bidirektional) oder popen (nur die Ausgaben lesen) hin. Da bekommst Du die Kommunikation mit Pipes fertig geliefert. Ob das in einem Webrequest zufriedenstellend funktioniert, ist allerdings die große Frage.
Heißt also:
(1) Aufgabe so planen, dass sie in max. 6 autarken Teilbereichen lösbar ist (bei 8 Kernen. Einer für den Webserver, einer für's OS, 6 für die Arbeit) (2) Je Teilbereich: Daten für die Aufgabe isolieren, Worker mit proc_open starten, Dateien in seine Eingangspipe jagen, Eingangspipe schließen (3) Ggf. noch einen Rest der Aufgabe selbst bearbeiten (4) Die Output-Streams der Worker round robin nach Antworten abfragen, Daten einlesen, ggf. zwischenspeichern, ggf. gleich integrieren, bis alle Worker fertig sind (5) Gesamtlösung präsentieren.
Das ist NICHT trivial, nutzt aber alle Kerne des Prozessors.
Eine generischere Lösung würde das nicht mit proc_open, sondern, wie erwähnt, mit HTTP Requests machen und die Verteilung auf Worker dem Apache überlassen. Die HTTP Lösung skaliert besser, weil man nämlich nach Bedarf Requeste an andere Maschinen schicken kann. Sofern sich die Aufgabe soweit fragmentieren lässt und die Request-Latenzen hinnehmbar sind, heißt das,
Rolf
sumpsi - posui - obstruxi