Anzahl Max-Fibers bei vorgegebener Hardware

[Rolf B]

Hallo Simone,

oha. Das sieht komplex aus 😉

na dann wirds eben synchron innerhalb des Fibers ausgeführt ;O) und der Array mit den *.jsons ggf. aufgesplittet

Jeder Fiber wird sofort gestartet ($fiber->start();) und führt seine Aufgabe komplett durch.

Und was ich Dir klarmachen will, ist, dass Du dann auf die Fibers komplett verzichten kannst. Weil sie Dir nur technischen Overhead bescheren.

Sehe ich das im neuen Code richtig, dass processStelleJsonContent mittels addAsyncQuery in $globalAsyncQueries eine Anzahl Queries hinterlegt und diese dann mit executeAllAsyncQueries() ausgeführt werden?

Und zwar mit MYSQLI_ASYNC, gefolgt von einer Warteschleife, die auf das Ende der asynchronen Query wartet?

Sehe ich das richtig, dass executeAllAsyncQueries() nicht in den Fibers läuft, sondern unabhängig davon?

Wenn das so ist, kannst Du auch auf die async Queries komplett verzichten. Du hast die Query zwar asynchron gestartet, wartest danach aber in einer Schleife auf's Ergebnis und machst sie damit wieder synchron.

D.h. du hast Dir eine Menge technischen Overhead geschaffen, und er bringt Dir keinerlei Performancevorteile.

Dein Design braucht einen Neuanfang, um die Fibers wirklich nutzen zu können.

Du kannst für jede Json-Datei eine Fiber erzeugen. Okay. Die Fiber-Funktion sollte

• die JSON-Datei lesen

• die gelesenen Daten für das DB-Update vorverarbeiten

• eine DB Connection öffnen

• für jedes erforderliche DB-Update

  1. den Update asynchron starten
  2. Fiber::suspend() aufrufen
  3. Ergebnis pollen
  4. Wenn nichts da ist, weiter mit 2 (also wieder suspenden)
  5. Fehler analysieren und loggen.

• die DB Connection schließen

• Mit Returncode FALSE zurückkehren

Im Fiber-Manager musst Du, nachdem alle Fibers gestartet sind, die Fiberliste solange immer wieder durchgehen und resume aufrufen, bis alle Fibers isTerminated gemeldet haben.

Auf diese Weile bekommst Du es hin, die Zeit, die die Queries auf dem DB Server verbringen, sinnvoll für andere Dinge zu nutzen. Aber wie gesagt: Nicht zu viele Fibers. Es ist schädlich, aus 100 SQL Connections heraus gleichzeitig Updates zu ballern. Eine Parallelisierung dieser Art setzt auch voraus, dass die Inserts oder Updates, die aus einer JSON-Datei entstehen, von denen aller anderen JSON-Dateien unabhängig sind. Wenn Du fachlich mehrere Abläufe parallel durchführst, ist diese Unabhängigkeit sehr wichtig, andernfalls erzeugst Du Datensalat.

Rolf