Capacité et dimensionnement

Combien de personnes une instance Archestack sert en même temps, de quels serveurs elle a besoin pour cela, et combien d'espaces de travail un serveur de base de données accueille. Chaque chiffre de cette page a été mesuré lors de tests de charge le 23 septembre 2026, avec des personnes simulées qui se connectent et travaillent dans l'application. Aucun n'est une projection : une installation plus grande se dimensionne en blocs entiers d'une taille testée.

En un coup d'œil

Tous ces chiffres sont obtenus avec les mises à jour en direct désactivées. Lorsqu'elles sont activées, ce qui est le cas par défaut, un espace de travail reste confortable jusqu'à environ 100 personnes en même temps.

Comment se déroulent les tests

• Les personnes. Chaque personne simulée se connecte avec son propre compte, consulte des listes et des enregistrements, fait des recherches, enregistre des modifications et ouvre un tableau de bord, avec une pause de 6 secondes en moyenne entre deux clics. Un quart d'entre elles utilisent le builder, les autres l'application publiée. "Personnes en même temps" compte les personnes qui cliquent au même moment, pas les comptes.
• Les paliers. Les personnes sont ajoutées sur 45 secondes, puis maintenues pendant 3 minutes. Chaque chiffre provient de ces 3 minutes stables.
• Rapide. Un palier est considéré comme rapide quand 95 % des chargements de page se terminent en moins d'une seconde et que moins de 1 % des requêtes échouent. Un chargement de page va du clic jusqu'à la dernière donnée affichée sur la page.
• La machine. Un seul PC de bureau équipé d'un Intel Core i9-12900KF et de 96 Go de mémoire. Chaque serveur tournait dans un conteneur disposant de ses propres cœurs de processeur, et le générateur de charge avait lui aussi ses propres cœurs. PostgreSQL 16, PgBouncer 1.25 là où il était utilisé, limitation de débit activée.

Un espace de travail, de nombreuses personnes

Une entreprise dont tout le monde travaille dans le même espace de travail, avec 2 500 clients, 25 000 commandes et 75 000 lignes de commande, sur un serveur d'application de 4 cœurs et un serveur de base de données de 2 cœurs :

Au-delà de 1 000 personnes, le générateur de charge manquait de processeur, si bien que la limite d'un espace de travail n'a pas été trouvée. À 1 000, aucun des deux serveurs n'utilisait un cœur entier.

Mises à jour en direct

Par défaut, chaque ligne enregistrée est poussée vers chaque écran ouvert qui l'affiche, et chacun de ces écrans recharge son enregistrement, ses listes liées et leurs libellés. Ce coût croît avec le carré du nombre de personnes dans un espace de travail. Sur le même build et les mêmes serveurs, environ 100 personnes en même temps travaillaient confortablement avec les mises à jour en direct activées, contre 1 000 avec elles désactivées ; à 200 personnes, 86 % de toutes les requêtes étaient ces rechargements.

Désactivez-les avec Realtime__EntityChanges=false sur le serveur d'application. Les écrans ouverts affichent alors la modification d'un collègue à leur prochain chargement. L'enregistrement des modifications, la recherche, les notifications et l'affichage des autres personnes présentes sur une page fonctionnent comme avant. Tous les autres chiffres de cette page sont obtenus avec les mises à jour en direct désactivées.

Plusieurs entreprises sur une instance

Des entreprises de 100 personnes chacune, chaque entreprise étant un espace de travail avec sa propre copie de l'application (500 clients, 5 000 commandes et 15 000 lignes de commande), sur deux tailles de serveurs :

Le premier chiffre de chaque paire correspond au serveur d'application, le second au serveur de base de données. En règle générale, 1 000 personnes en même temps utilisent environ un demi-cœur applicatif et un demi-cœur de base de données.

Là où un serveur de base de données atteint sa limite

En connexion directe, chaque espace de travail conserve ses propres pools de connexions, qui grandissent avec la charge. À 5 000 personnes, le serveur de base de données de la paire 4 + 4 a atteint près de 2 000 connexions et les chargements de page se sont effondrés ; une paire 6 + 6 ne s'est jamais stabilisée. Via PgBouncer en mode transaction, les bases de données des espaces de travail partagent des pools de quelques connexions chacun : la paire 4 + 4 a alors servi 4 000 personnes avec 95 % des pages en moins de 54 ms sur 400 connexions, et une paire 8 + 8 a tenu 8 000 personnes sur 757. Ce test 8 + 8 partageait les cœurs du PC avec le générateur de charge ; il ne renseigne donc que sur les connexions et n'est pas utilisé pour le dimensionnement.

Des serveurs pour davantage de personnes

Un bloc est la paire testée : un serveur d'application de 4 cœurs et un serveur de base de données de 4 cœurs avec PgBouncer, compté pour 4 000 personnes afin de garder une certaine marge. Une installation plus grande ajoute des blocs entiers.

Aujourd'hui, chaque bloc est un déploiement à part entière, et une entreprise vit sur un seul bloc. Répartir les entreprises sur plusieurs blocs derrière une seule adresse et une seule authentification n'existe pas encore.

De nombreux espaces de travail sur un serveur de base de données

Un test distinct a ajouté des espaces de travail à un même serveur de base de données, dont 50 utilisés à tout moment, jusqu'à 5 000 espaces de travail :

• Aucun échec. 5 000 espaces de travail sans aucune inscription ni requête en échec.
• L'inactivité ne coûte rien. Un espace de travail que personne n'utilise n'occupe aucune connexion à la base de données. Après six minutes sans utilisation, les 5 000 occupaient 3 connexions à eux tous.
• Un nouvel espace de travail en une seconde environ. 0,9 seconde en médiane, les deux bases de données créées et préparées.
• Environ 18 Mo de disque par espace de travail : deux bases de données et une petite application, avant vos propres données.

Le nombre de connexions occupées reste stable quel que soit le nombre d'espaces de travail, car seuls ceux qui sont utilisés en occupent. Deux choses augmentent avec le nombre d'espaces de travail : la mémoire du serveur d'application, et le temps qu'il faut après un redémarrage pour que l'API réponde à nouveau, qui a atteint près de quatre minutes à 5 000 espaces de travail. Planifiez les redémarrages d'une grande instance en conséquence.

Les paramètres derrière ces chiffres

• Mises à jour en direct désactivées : Realtime__EntityChanges=false sur le serveur d'application, voir plus haut.
• Mémoire partagée de la base de données : shm_size: 1g sur le conteneur PostgreSQL. PostgreSQL conserve des statistiques pour chaque base de données en mémoire partagée, environ 55 Ko chacune, et Docker accorde 64 Mo à un conteneur sauf indication contraire. 1 Go couvre quelque 9 000 espaces de travail.
• Pooling de connexions : PgBouncer en mode transaction, avec une entrée de base de données générique pour qu'un nouvel espace de travail ne demande aucune configuration, 2 connexions par base de données avec 1 en réserve, et un plafond de connexions serveur d'au moins 4 par entreprise active et inférieur au max_connections de PostgreSQL. Un plafond plus serré oblige PgBouncer à fermer les connexions d'une entreprise pour ouvrir celles d'une autre : 400 connexions pour 150 entreprises ont saturé les deux serveurs avec ce va-et-vient. Les chaînes de connexion du serveur d'application portent No Reset On Close=true. La synchronisation de données avec des systèmes tiers utilise des tables temporaires, que le pooling en mode transaction ne conserve pas ; elle a donc toujours besoin d'une connexion directe.
• Maintenance de la base de données : avec des milliers de bases de données, un autovacuum_naptime plus long espace les passages que PostgreSQL effectue lui-même dans chaque base de données.

Ce que les chiffres ne couvrent pas

• Les processeurs cloud. Un processeur virtuel dans le cloud est généralement plus lent qu'un cœur de ce processeur de bureau.
• Le réseau et le navigateur. Les temps de page n'incluent ni le réseau entre les serveurs et vos utilisateurs, ni le temps que met le navigateur à dessiner la page.
• Des applications plus lourdes. Des pages avec davantage de listes liées, ou des tables plus volumineuses, coûtent plus cher par page que celles de l'application de test.
• Au-delà de 10 000 personnes. Rien ici n'est extrapolé au-delà d'une taille testée.

Pour aller plus loin

Espaces de travail et hébergement explique le choix entre un espace de travail par instance et plusieurs, ainsi que les deux façons d'exécuter les conteneurs.