2: De worker pool

De daemon houdt een pool van resident PHP workers per app. Elke worker start de app één keer op en beantwoordt vervolgens veel oproepen, waardoor de opstartkosten per oproep die het one-shot pad met zich meebrengt, worden geëlimineerd. Het is hetzelfde idee als de HTTP worker mode van FrankenPHP, maar dan voor niet-HTTP werk.

2.1: Het workerprotocol

Een worker draait php <app.php> phlo_serve, start de app op en leest vervolgens newline-gescheiden JSON op stdin, één verzoek tegelijk:

in   {"id", "target", "args"?, "stream"?}
out  {"t":"ready"}                                            // once, after boot
     {"id", "t":"line", "data"}                               // 0..N, only when streaming
     {"id", "t":"done", "result"} | {"id", "t":"error", "message"}   // exactly one, terminal

Gelijktijdigheid is gelijk aan de poolgrootte: een worker behandelt één oproep tegelijk, en de daemon plaatst de rest in de wachtrij totdat een worker weer beschikbaar is.

2.2: Per-aanroep reset

Tussen aanroepen reset een worker de status (phlo('tech/reset'), sessie sluiten, GC), precies zoals de FrankenPHP worker-lus, zodat de ene aanroep nooit in de andere lekt. Schrijf worker-veilige doelen: geen verzoek- of gebruikersstatus in statics, en commit of roll back DB-werk. Langdurige verbindingen die je expliciet markeert met objPers overleven; alles wat anders is, wordt gewist.

2.3: Dynamische sizing, recyclen

De pool past zichzelf aan: het spawn een worker wanneer er een oproep binnenkomt en er geen vrij is, tot een globale limiet van één minder dan het aantal cores, en oogst een worker zodra deze idle is. Niets is geconfigureerd.

Of een app one-shot draait (een nieuw proces per oproep, wat hot-reload mogelijk houdt) of op de resident pool (warme workers, geen opstart per oproep) is per host geconfigureerd in config/daemon.js (of per oproep voor CLI-dispatch): een build: true dev-app is one-shot, een release-app is gepoold. Twee guards houden een resident pool gezond: een timeout per oproep (een vastgelopen worker wordt gedood en opnieuw opgestart) en recycling (een worker wordt vervangen na een aantal oproepen, om eventuele langzame lekken te verminderen). Na een deploy, herstart de workers zodat ze de nieuwe build opnieuw laden.

2.4: Gezondheid

GET /health op de daemon rapporteert het totale aantal actieve workers ten opzichte van de limiet, elke pool gekoppeld aan het app-pad, de verbonden sockets per host, en de geconfigureerde hosts:

{
    "status": "ok",
    "workers": 5,
    "cap": 7,
    "pools": { "/srv/app/release/www/app.php": { "workers": 4, "busy": 1, "queued": 0 } },
    "sockets": { "app.example.com": { "tokens": 12, "sockets": 18 } },
    "registered": ["app.example.com", "dev.example.com"]
}

busy zijn de workers die momenteel een oproep uitvoeren en queued zijn de oproepen die wachten op een vrije worker; workers/cap is het actuele totaal ten opzichte van de limiet. Een busy die op de limiet zit met een groeiende queued betekent dat de node op capaciteit is: voeg nodes toe of geef het meer cores.