Capacità e dimensionamento

Quante persone serve contemporaneamente un'istanza Archestack, di quali server ha bisogno per farlo e quanti workspace contiene un solo server di database. Ogni cifra di questa pagina è stata misurata in test di carico il 23 settembre 2026, con persone simulate che accedono e lavorano nell'app. Nessuna è una proiezione: un'installazione più grande si dimensiona in blocchi interi di una dimensione testata.

In sintesi

Tutti questi valori sono con gli aggiornamenti in tempo reale disattivati. Con gli aggiornamenti attivi, che è l'impostazione predefinita, un workspace regge senza problemi fino a circa 100 persone contemporaneamente.

Come funzionano i test

• Persone. Ogni persona simulata accede con il proprio account e lavora su elenchi, record, ricerche, salvataggi e una dashboard, con una pausa media di 6 secondi tra un clic e l'altro. Un quarto di loro usa il builder, il resto l'app pubblicata. "Persone contemporaneamente" conta le persone che fanno clic nello stesso momento, non gli account.
• Fasi. Le persone vengono aggiunte nell'arco di 45 secondi e poi mantenute per 3 minuti. Ogni cifra viene da quei 3 minuti stabili.
• Veloce. Una fase conta come veloce quando il 95% dei caricamenti di pagina termina entro 1 secondo e meno dell'1% delle richieste fallisce. Un caricamento di pagina va dal clic all'ultimo dato della pagina.
• Macchina. Un PC desktop con un Intel Core i9-12900KF e 96 GB di memoria. Ogni server girava in un container con core del processore tutti suoi, e anche il generatore di carico aveva i propri core. PostgreSQL 16, PgBouncer 1.25 dove è stato usato, limiti sul numero di richieste attivi.

Un workspace, molte persone

Un'unica azienda con tutti nello stesso workspace, con 2.500 clienti, 25.000 ordini e 75.000 righe d'ordine, su un server applicativo da 4 core e un server di database da 2 core:

Oltre le 1.000 persone il generatore di carico ha esaurito il processore, quindi il limite di un workspace non è stato trovato. A 1.000 persone, nessuno dei due server usava un core intero.

Aggiornamenti in tempo reale

Per impostazione predefinita, ogni riga salvata viene inviata a ogni schermata aperta che la mostra, e ognuna di quelle schermate ricarica il proprio record, i propri elenchi collegati e le loro etichette. Questo costo cresce con il quadrato del numero di persone in un workspace. Sulla stessa build e sugli stessi server, circa 100 persone contemporaneamente lavoravano senza problemi con gli aggiornamenti in tempo reale attivi, contro 1.000 con gli aggiornamenti disattivati; a 200 persone, l'86% di tutte le richieste erano quei ricaricamenti.

Disattivali con Realtime__EntityChanges=false sul server applicativo. Le schermate aperte mostrano allora la modifica di un collega la volta successiva che vengono caricate. Salvare, cercare, le notifiche e vedere chi altro è su una pagina funzionano come prima. Ogni altra cifra di questa pagina è con gli aggiornamenti in tempo reale disattivati.

Molte aziende su un'istanza

Aziende di 100 persone ciascuna, ogni azienda un workspace con la propria copia dell'app (500 clienti, 5.000 ordini e 15.000 righe d'ordine), su due dimensioni di server:

Il primo numero di ogni coppia è il server applicativo, il secondo il server di database. Come regola pratica, 1.000 persone contemporaneamente usano circa mezzo core applicativo e mezzo core del database.

Dove si esaurisce un server di database

Con una connessione diretta, ogni workspace mantiene pool di connessioni propri, che crescono con il carico. A 5.000 persone il server di database 4 + 4 ha raggiunto quasi 2.000 connessioni e i caricamenti di pagina sono crollati; una coppia 6 + 6 non si è mai stabilizzata. Tramite PgBouncer in modalità transaction, i database dei workspace condividono pool di poche connessioni ciascuno: la coppia 4 + 4 ha allora servito 4.000 persone con il 95% delle pagine entro 54 ms su 400 connessioni, e una coppia 8 + 8 ha retto 8.000 persone su 757. Quella prova 8 + 8 condivideva i core del PC con il generatore di carico, quindi mostra solo le connessioni e non viene usata per il dimensionamento.

Server per più persone

Un blocco è la coppia testata: un server applicativo da 4 core e un server di database da 4 core con PgBouncer, contato per 4.000 persone così da mantenere un po' di margine. Un'installazione più grande aggiunge blocchi interi.

Oggi ogni blocco è un deployment a sé, e un'azienda vive su un solo blocco. Distribuire le aziende su più blocchi dietro un unico indirizzo e un unico accesso non è ancora stato realizzato.

Molti workspace su un server di database

Un test separato ha continuato ad aggiungere workspace a un server di database, con 50 di essi in uso in ogni momento, fino a 5.000 workspace:

• Nessun errore. 5.000 workspace senza una registrazione fallita né una richiesta fallita.
• L'inattività non costa nulla. Un workspace che nessuno usa non tiene aperta nessuna connessione al database. Dopo sei minuti senza utilizzo, tutti i 5.000 workspace tenevano aperte 3 connessioni in totale.
• Un nuovo workspace in circa un secondo. 0,9 secondi di mediana, con entrambi i database creati e preparati.
• Circa 18 MB di disco per workspace: due database e una piccola app, senza contare i tuoi dati.

Le connessioni aperte restano costanti a prescindere dal numero di workspace, perché solo quelli in uso ne tengono aperte. Due cose invece crescono con il numero di workspace: la memoria del server applicativo e il tempo che serve dopo un riavvio perché l'API risponda di nuovo, che ha raggiunto quasi quattro minuti a 5.000 workspace. Pianifica di conseguenza i riavvii di un'istanza grande.

Le impostazioni dietro questi numeri

• Aggiornamenti in tempo reale disattivati: Realtime__EntityChanges=false sul server applicativo, vedi sopra.
• Memoria condivisa del database: shm_size: 1g sul container PostgreSQL. PostgreSQL tiene le statistiche di ogni database in memoria condivisa, circa 55 KB ciascuno, e Docker dà a un container 64 MB se non gli si indica altro. 1 GB copre circa 9.000 workspace.
• Pool di connessioni: PgBouncer in modalità transaction, con una voce di database wildcard così che un nuovo workspace non richieda nessuna configurazione, 2 connessioni per database con 1 di riserva, e un tetto alle connessioni verso il server di almeno 4 per ogni azienda attiva e al di sotto del max_connections di PostgreSQL. Un tetto più basso fa sì che PgBouncer chiuda le connessioni di un'azienda per aprire quelle di un'altra: 400 connessioni per 150 aziende hanno saturato entrambi i server con questo continuo ricambio. Le stringhe di connessione del server applicativo contengono No Reset On Close=true. La sincronizzazione dei dati con sistemi di terze parti usa tabelle temporanee, che il pooling in modalità transaction non conserva, quindi ha ancora bisogno di una connessione diretta.
• Manutenzione del database: con migliaia di database, un autovacuum_naptime più lungo distribuisce nel tempo le visite che PostgreSQL stesso fa a ogni database.

Cosa i numeri non coprono

• Processori cloud. Un processore virtuale nel cloud di solito è più lento di un core di questo processore desktop.
• La rete e il browser. I tempi di pagina escludono la rete tra i server e i tuoi utenti, e il tempo che il browser impiega a disegnare la pagina.
• App più pesanti. Le pagine con più elenchi collegati, o con tabelle più grandi, costano di più per pagina rispetto a quelle dell'app di test.
• Oltre le 10.000 persone. Nulla qui è estrapolato oltre una dimensione testata.

Dove andare dopo

Workspace e hosting spiega la scelta tra un workspace per istanza e più workspace per istanza, e i due modi di eseguire i container.