4: Socket monitoring

Omdat elke verbinding via jouw hooks gaat, kun je sockets zien en beheren met gewone Phlo-modellen, zonder speciale tools nodig te hebben.

4.1: Aanwezigheid

Houd bij wie er verbonden is door een rij te schrijven in wsConnect en deze te verwijderen in wsClose:

function wsConnect($wsHost, $wsToken, $wsSocket){
	type_presence::create(socket: $wsSocket, token: substr((string)$wsToken, 0, 8), since: time())
	return true
}
function wsClose($wsHost, $wsToken, $wsSocket){
	type_presence::delete('socket=?', $wsSocket)
}

De live telling is dan gewoon count(type_presence::records()), die je naar iedereen kunt uitzenden bij elke wijziging.

4.2: Een connect/disconnect feed

Voeg elk lifecycle-evenement toe aan een logmodel en je hebt een audittrail en een live feed. De /monitor pagina van de demo rendert de log en werkt de online telling en de feed bij via wsCast terwijl sockets komen en gaan.

4.3: Gezondheid

Een GET /health op de daemon (bijv. 127.0.0.1:3001) rapporteert zowel de verbindingszijde als de worker pools op één plek, aangezien ze één proces zijn:

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

sockets telt het aantal actieve verbindingen per host (tokens en sockets); pools zijn de per-app worker statistieken, waarbij busy de workers zijn die momenteel een gebeurtenis afhandelen en queued de gebeurtenissen die wachten op een vrije worker; workers/cap is het totale aantal actieve workers ten opzichte van de limiet. De pool groeit zelf naar de limiet en verwijdert inactieve workers, dus een busy die op de limiet blijft met een groeiende queued betekent dat de node op capaciteit is.

4.4: Beperkingen

Phlo Realtime is de ingebouwde WebSocket-laag van de daemon: één proces beheert de sockets en draait de PHP. In de one-shot modus (een build: true app) start de daemon een handler per gebeurtenis, waardoor er een kleine kosten per gebeurtenis is in vergelijking met een proces dat staat in het geheugen; draai de host als een release build en de daemon serveert het vanuit zijn residentiële pool, waardoor die kosten worden verwijderd en de doorvoer wordt geschaald. Hoe dan ook, je behoudt hetzelfde stateless model als de rest van Phlo en er is geen extra taal. Voor zeer hoge frequentie streaming (veel gebeurtenissen per seconde per socket) kan een dedicated streaming server nog steeds beter passen.