Scalabilità e prestazioni

EntityFlow è progettato per rimanere reattivo man mano che diagrammi e team crescono. Punta a due traguardi di SLO:

Traguardo	Tabelle	Editor concorrenti	Stato
B	~500	~15	Raggiunto
C	~3.000	25+	Obiettivo

Come l'editor rimane veloce

Il canvas mantiene un'interazione fluida su larga scala grazie a diverse tecniche che operano insieme:

• Virtualizzazione del viewport — viene renderizzato solo ciò che è sullo schermo.
• Livelli di dettaglio — le tabelle degradano in modo graduale man mano che si riduce lo zoom: completo → intestazione → riquadro → punto.
• Culling tramite quadtree — l'indicizzazione spaziale salta a basso costo la geometria fuori schermo.
• Presenza limitata — gli aggiornamenti di cursore e selezione sono limitati nella frequenza affinché una stanza affollata non sommerga i client.

Come la persistenza rimane economica

• Scritture con debounce — gli aggiornamenti CRDT vengono raggruppati prima di raggiungere il database (vedi EF_COLLAB_DEBOUNCE_MS nel Riferimento di configurazione).
• Proiezione incrementale — vengono riproiettate solo le entità modificate, mai l'intero diagramma.

Eseguire più nodi server

Un singolo nodo gestisce da solo un carico di lavoro considerevole e non necessita di Redis.

Per eseguire più di una replica del server, abilita la diffusione tramite Redis in modo che la consapevolezza (presenza) e gli aggiornamenti dei documenti si propaghino a tutti i pod:

export EF_REALTIME_REDIS_ENABLED=true
export EF_REALTIME_REDIS_URL="redis://redis:6379"

Questo è necessario ogni volta che esegui più di una replica — senza una consapevolezza condivisa, i nodi divergono e gli editor su pod diversi vedono uno stato incoerente.

warning

Su Kubernetes, il chart Helm impone questo: replicaCount > 1 richiede redis.enabled=true, altrimenti il chart non viene renderizzato. Vedi Kubernetes e Helm.

I deployment a nodo singolo dovrebbero lasciare Redis disabilitato.