Kapazität und Dimensionierung

Wie viele Personen eine Archestack-Instanz gleichzeitig bedient, welche Server sie dafür braucht und wie viele Workspaces ein Datenbankserver trägt. Jede Zahl auf dieser Seite wurde am 23. September 2026 in Lasttests gemessen, mit simulierten Personen, die sich anmelden und durch die App arbeiten. Nichts davon ist hochgerechnet: Eine größere Installation wird in ganzen Blöcken einer getesteten Größe dimensioniert.

Auf einen Blick

Alle diese Werte gelten mit ausgeschalteten Live-Updates. Sind sie eingeschaltet, was der Standard ist, läuft ein Workspace bis etwa 100 Personen gleichzeitig problemlos.

Wie die Tests funktionieren

• Personen. Jede simulierte Person meldet sich mit ihrem eigenen Konto an und arbeitet sich durch Listen, Datensätze, Suchen, Speichervorgänge und ein Dashboard, mit durchschnittlich 6 Sekunden Pause zwischen den Klicks. Ein Viertel von ihnen nutzt den Builder, der Rest die veröffentlichte App. "Personen gleichzeitig" zählt Personen, die zur selben Zeit klicken, nicht Konten.
• Stufen. Personen werden über 45 Sekunden hinweg hinzugefügt, dann bleibt ihre Zahl 3 Minuten lang gleich. Jede Zahl stammt aus diesen gleichbleibenden 3 Minuten.
• Schnell. Eine Stufe gilt als schnell, wenn 95 % der Seitenaufrufe innerhalb von 1 Sekunde fertig sind und weniger als 1 % der Anfragen fehlschlagen. Ein Seitenaufruf reicht vom Klick bis zum letzten Stück Daten auf der Seite.
• Rechner. Ein Desktop-PC mit einem Intel Core i9-12900KF und 96 GB Arbeitsspeicher. Jeder Server lief in einem Container mit eigenen Prozessorkernen, und auch der Lastgenerator hatte eigene Kerne. PostgreSQL 16, PgBouncer 1.25 dort, wo er eingesetzt wurde, Rate Limits aktiv.

Ein Workspace, viele Personen

Ein Unternehmen, in dem alle im selben Workspace arbeiten, mit 2.500 Kunden, 25.000 Aufträgen und 75.000 Auftragspositionen, auf einem Anwendungsserver mit 4 Kernen und einem Datenbankserver mit 2 Kernen:

Oberhalb von 1.000 Personen reichte dem Lastgenerator der Prozessor nicht mehr, daher wurde das Limit eines Workspaces nicht gefunden. Bei 1.000 nutzte keiner der beiden Server einen ganzen Kern.

Live-Updates

Standardmäßig wird jede gespeicherte Zeile an jeden geöffneten Bildschirm übertragen, der sie anzeigt, und jeder dieser Bildschirme lädt seinen Datensatz, seine zugehörigen Listen und deren Beschriftungen neu. Dieser Aufwand wächst mit dem Quadrat der Zahl der Personen in einem Workspace. Mit demselben Build auf denselben Servern liefen etwa 100 Personen gleichzeitig problemlos mit eingeschalteten Live-Updates, gegenüber 1.000 mit ausgeschalteten; bei 200 Personen waren 86 % aller Anfragen solche Neuladevorgänge.

Schalte sie mit Realtime__EntityChanges=false auf dem Anwendungsserver aus. Geöffnete Bildschirme zeigen die Änderung eines Kollegen dann beim nächsten Laden. Speichern, Suchen, Benachrichtigungen und die Anzeige, wer sonst noch auf einer Page ist, funktionieren wie bisher. Jede andere Zahl auf dieser Seite gilt mit ausgeschalteten Live-Updates.

Viele Unternehmen auf einer Instanz

Unternehmen mit je 100 Personen, jedes Unternehmen ein Workspace mit eigener Kopie der App (500 Kunden, 5.000 Aufträge und 15.000 Auftragspositionen), auf zwei Servergrößen:

Die erste Zahl jedes Paares gilt für den Anwendungsserver, die zweite für den Datenbankserver. Als Faustregel nutzen 1.000 Personen gleichzeitig etwa einen halben Anwendungskern und einen halben Datenbankkern.

Wo ein Datenbankserver an seine Grenze stößt

Bei direkter Verbindung hält jeder Workspace eigene Verbindungspools, und sie wachsen mit der Last. Bei 5.000 Personen erreichte der Datenbankserver des Paares mit 4 + 4 Kernen fast 2.000 Verbindungen, und die Seitenaufrufe brachen ein; ein Paar mit 6 + 6 Kernen kam überhaupt nie zur Ruhe. Über PgBouncer im Transaktionsmodus teilen sich die Datenbanken der Workspaces Pools von jeweils wenigen Verbindungen: Das Paar mit 4 + 4 Kernen bediente dann 4.000 Personen mit 95 % der Seiten innerhalb von 54 ms bei 400 Verbindungen, und ein Paar mit 8 + 8 Kernen trug 8.000 Personen bei 757. Dieser Lauf mit 8 + 8 Kernen teilte sich die Kerne des PCs mit dem Lastgenerator, zeigt also nur die Verbindungen und wird nicht für die Dimensionierung verwendet.

Server für mehr Personen

Ein Block ist das getestete Paar: ein Anwendungsserver mit 4 Kernen und ein Datenbankserver mit 4 Kernen und PgBouncer, gerechnet mit 4.000 Personen, damit er etwas Reserve behält. Eine größere Installation fügt ganze Blöcke hinzu.

Heute ist jeder Block ein eigenes Deployment, und ein Unternehmen liegt auf einem Block. Unternehmen hinter einer Adresse und einer Anmeldung auf mehrere Blöcke zu verteilen, ist noch nicht umgesetzt.

Viele Workspaces auf einem Datenbankserver

Ein separater Test fügte einem Datenbankserver laufend Workspaces hinzu, bis 5.000 Workspaces erreicht waren, wobei jederzeit 50 davon genutzt wurden:

• Keine Fehler. 5.000 Workspaces ohne eine fehlgeschlagene Registrierung oder eine fehlgeschlagene Anfrage.
• Leerlauf kostet nichts. Ein Workspace, den niemand nutzt, hält keine Datenbankverbindung. Nach sechs Minuten ohne Nutzung hielten alle 5.000 zusammen 3 Verbindungen.
• Ein neuer Workspace in etwa einer Sekunde. 0,9 Sekunden im Median, beide Datenbanken angelegt und vorbereitet.
• Etwa 18 MB Plattenplatz pro Workspace: zwei Datenbanken und eine kleine App, bevor deine eigenen Daten dazukommen.

Die gehaltenen Verbindungen bleiben auf gleichem Niveau, egal wie viele Workspaces es gibt, weil nur die genutzten welche halten. Zwei Dinge wachsen mit der Zahl der Workspaces: der Arbeitsspeicher des Anwendungsservers und die Zeit, bis die API nach einem Neustart wieder antwortet, die bei 5.000 Workspaces fast vier Minuten erreichte. Plane Neustarts einer großen Instanz entsprechend.

Einstellungen hinter diesen Zahlen

• Live-Updates aus: Realtime__EntityChanges=false auf dem Anwendungsserver, siehe oben.
• Gemeinsamer Speicher der Datenbank: shm_size: 1g auf dem PostgreSQL-Container. PostgreSQL hält Statistiken für jede Datenbank im gemeinsamen Speicher, etwa 55 KB pro Datenbank, und Docker gibt einem Container 64 MB, sofern nichts anderes angegeben ist. 1 GB reicht für rund 9.000 Workspaces.
• Verbindungspooling: PgBouncer im Transaktionsmodus, mit einem Wildcard-Datenbankeintrag, damit ein neuer Workspace keine Konfiguration braucht, 2 Verbindungen pro Datenbank mit 1 in Reserve und einer Obergrenze für Serververbindungen von mindestens 4 pro aktivem Unternehmen und unterhalb von max_connections von PostgreSQL. Eine knappere Obergrenze lässt PgBouncer die Verbindungen eines Unternehmens schließen, um die eines anderen zu öffnen: 400 Verbindungen für 150 Unternehmen lasteten mit diesem Hin und Her beide Server voll aus. Die Connection Strings des Anwendungsservers enthalten No Reset On Close=true. Die Datensynchronisierung mit anderen Systemen nutzt temporäre Tabellen, die das Pooling im Transaktionsmodus nicht erhält, und braucht deshalb weiterhin eine direkte Verbindung.
• Datenbankwartung: Bei Tausenden von Datenbanken zieht ein längeres autovacuum_naptime die Besuche auseinander, die PostgreSQL selbst jeder Datenbank abstattet.

Was die Zahlen nicht abdecken

• Cloud-Prozessoren. Ein virtueller Prozessor in der Cloud ist meist langsamer als ein Kern dieses Desktop-Prozessors.
• Das Netzwerk und der Browser. Die Seitenzeiten enthalten weder das Netzwerk zwischen den Servern und deinen Benutzern noch die Zeit, die der Browser zum Zeichnen der Seite braucht.
• Aufwendigere Apps. Pages mit mehr zugehörigen Listen oder größere Tabellen kosten pro Page mehr als bei der Test-App.
• Über 10.000 Personen. Nichts hier wird über eine getestete Größe hinaus hochgerechnet.

Wie es weitergeht

Workspaces und Hosting erklärt die Wahl zwischen einem Workspace pro Instanz und mehreren sowie die zwei Wege, die Container zu betreiben.