Hallo Simone,

dein Codebeispiel zeigt einen Fiber-Scheduler, ähnlich dem, wie er auch im PHP Handbuch gezeigt wird. Aber er ist buggy - falls deine Fibers mehr als einen suspend-Aufruf erhalten, wird er nach dem zweiten Suspend nicht mehr zurückkommen.

Nochmal: Fibers sind keine Threads. Solange im Fiber-Code kein Fiber::suspend() steht, läuft der Fiber komplett im start() Aufruf durch, womit die Fibers vergebliche Mühe sind. Dein Code wird dann niemals an die Stelle kommen, wo resume aufgerufen wird.

Wenn Du die SQL-Statements nicht asynchron absetzt, hast Du auch keinen Ort im Code, wo Dir ein suspend etwas nützen könnte. Du kannst zwar nach einem nicht-asynchronen SQL Statement Fiber::suspend() aufrufen, aber du gewinnst damit nichts.

Dein Log zeigt ja auch, dass die Fibers die Laufzeit nicht wesentlich beeinflussen. Bei einer Million Logfiles sind Schwankungen von 3 Minuten nicht ungewöhnlich. Den Ausreißer bei 20 Fibers kann ich aber nicht erklären.

Dass bei 20000 Fibers und 200000 Fibers der Speicherbedarf fast gleich ist, ist ebenfalls ein Hinweis. Ohne suspend läuft jeder Fiber komplett durch und es wird kein Speicher gebraucht, um seinen Kontext zu speichern. Mit asynchronem SQL und vorhandenem suspend würde dein Programm auch abstürzen, denn es scheint, als hättest Du nur eine einzige SQL Connection offen ($conn_ln).

Natürlich mag ich mich irren, weil ich nicht den ganzen Code sehe. Aber bisher habe ich den Eindruck, dass Du eine wunderschön geformte und mit einem prächtigen Etikett versehene Flasche voller – Schlangenöl zubereitet hast.

Rolf