Capaciteit en dimensionering

Hoeveel mensen een Archestack-instantie tegelijk bedient, welke servers ze daarvoor nodig heeft, en hoeveel werkruimtes één databaseserver aankan. Elk cijfer op deze pagina is gemeten in belastingstests op 23 september 2026, met gesimuleerde mensen die zich aanmelden en door de app werken. Niets ervan is een projectie: een grotere installatie wordt gedimensioneerd in hele blokken van een geteste grootte.

In één oogopslag

Dit alles met live-updates uitgeschakeld. Staan ze aan, wat de standaard is, dan blijft één werkruimte comfortabel tot ongeveer 100 mensen tegelijk.

Hoe de tests werken

• Mensen. Elke gesimuleerde persoon meldt zich aan met een eigen account en doorloopt lijsten, records, zoekopdrachten, opslagacties en een dashboard, met gemiddeld 6 seconden pauze tussen twee klikken. Een kwart van hen gebruikt de builder, de rest de gepubliceerde app. "Mensen tegelijk" telt mensen die op hetzelfde moment klikken, geen accounts.
• Stappen. Mensen worden in 45 seconden toegevoegd, waarna dat aantal 3 minuten wordt aangehouden. Elk cijfer komt uit die stabiele 3 minuten.
• Snel. Een stap telt als snel wanneer 95% van de pagina's binnen 1 seconde geladen is en minder dan 1% van de verzoeken mislukt. Het laden van een pagina loopt van de klik tot het laatste stuk data op de pagina.
• Machine. Eén desktop-pc met een Intel Core i9-12900KF en 96 GB geheugen. Elke server draaide in een container met eigen processorkernen, en de belastingsgenerator had ook eigen kernen. PostgreSQL 16, PgBouncer 1.25 waar die werd gebruikt, rate limits aan.

Eén werkruimte, veel mensen

Eén bedrijf met iedereen in dezelfde werkruimte, met 2.500 klanten, 25.000 orders en 75.000 orderregels, op een applicatieserver met 4 kernen en een databaseserver met 2 kernen:

Boven 1.000 mensen had de belastingsgenerator geen processorcapaciteit meer, dus de grens van één werkruimte is niet gevonden. Bij 1.000 gebruikte geen van beide servers een volledige kern.

Live-updates

Standaard wordt elke opgeslagen rij doorgestuurd naar elk open scherm waarop ze staat, en elk van die schermen laadt zijn record, zijn gerelateerde lijsten en hun labels opnieuw. Die kosten groeien met het kwadraat van het aantal mensen in een werkruimte. Op dezelfde build en dezelfde servers bleven ongeveer 100 mensen tegelijk comfortabel met live-updates aan, tegenover 1.000 met live-updates uit; bij 200 mensen bestond 86% van alle verzoeken uit die herladingen.

Zet ze uit met Realtime__EntityChanges=false op de applicatieserver. Open schermen tonen de wijziging van een collega dan de volgende keer dat ze laden. Opslaan, zoeken, meldingen en zien wie er nog op een pagina zit, werken zoals voorheen. Elk ander cijfer op deze pagina is met live-updates uit.

Veel bedrijven op één instantie

Bedrijven van elk 100 mensen, elk bedrijf een werkruimte met een eigen kopie van de app (500 klanten, 5.000 orders en 15.000 orderregels), op twee servergroottes:

Het eerste cijfer van elk paar is de applicatieserver, het tweede de databaseserver. Als vuistregel gebruiken 1.000 mensen tegelijk ongeveer een halve applicatiekern en een halve databasekern.

Waar één databaseserver tekortschiet

Bij een directe verbinding houdt elke werkruimte eigen verbindingspools aan, en die groeien met de belasting. Bij 5.000 mensen kwam de databaseserver van het 4 + 4-paar op bijna 2.000 verbindingen en stortten de laadtijden van de pagina's in; een 6 + 6-paar werd helemaal niet stabiel. Via PgBouncer in transactiemodus delen de databases van de werkruimtes pools van elk een paar verbindingen: het 4 + 4-paar bediende dan 4.000 mensen met 95% van de pagina's binnen 54 ms op 400 verbindingen, en een 8 + 8-paar kon 8.000 mensen aan op 757. Die 8 + 8-run deelde de kernen van de pc met de belastingsgenerator, dus hij toont alleen de verbindingen en wordt niet gebruikt voor de dimensionering.

Servers voor meer mensen

Een blok is het geteste paar: een applicatieserver met 4 kernen en een databaseserver met 4 kernen met PgBouncer, gerekend op 4.000 mensen zodat er wat reserve overblijft. Een grotere installatie voegt hele blokken toe.

Op dit moment is elk blok een eigen deployment, en een bedrijf staat op één blok. Bedrijven spreiden over meerdere blokken achter één adres en één aanmelding is nog niet gebouwd.

Veel werkruimtes op één databaseserver

Een aparte test bleef werkruimtes toevoegen aan één databaseserver, met er op elk moment 50 in gebruik, tot 5.000 werkruimtes:

• Geen fouten. 5.000 werkruimtes zonder één mislukte registratie of mislukt verzoek.
• Niet in gebruik kost niets. Een werkruimte die niemand gebruikt, houdt geen databaseverbinding open. Na zes minuten zonder gebruik hielden alle 5.000 samen 3 verbindingen open.
• Een nieuwe werkruimte in ongeveer een seconde. Mediaan 0,9 seconden, met beide databases aangemaakt en voorbereid.
• Ongeveer 18 MB schijfruimte per werkruimte: twee databases en een kleine app, vóór je eigen data.

Het aantal open verbindingen blijft vlak, hoeveel werkruimtes er ook zijn, omdat alleen de werkruimtes in gebruik er openhouden. Twee dingen groeien wel mee met het aantal werkruimtes: het geheugen van de applicatieserver, en de tijd die een herstart duurt tot de API weer antwoordt, die bij 5.000 werkruimtes bijna vier minuten bereikte. Plan herstarts van een grote instantie daarop.

Instellingen achter deze cijfers

• Live-updates uit: Realtime__EntityChanges=false op de applicatieserver, zie hierboven.
• Gedeeld geheugen van de database: shm_size: 1g op de PostgreSQL-container. PostgreSQL houdt voor elke database statistieken bij in gedeeld geheugen, ongeveer 55 KB per database, en Docker geeft een container 64 MB tenzij je iets anders opgeeft. 1 GB volstaat voor zo'n 9.000 werkruimtes.
• Verbindingspooling: PgBouncer in transactiemodus, met een wildcardregel voor de databases zodat een nieuwe werkruimte geen configuratie nodig heeft, 2 verbindingen per database met 1 in reserve, en een plafond voor serververbindingen van minstens 4 per druk bedrijf en onder de max_connections van PostgreSQL. Bij een krapper plafond sluit PgBouncer de verbindingen van het ene bedrijf om die van een ander te openen: 400 verbindingen voor 150 bedrijven brachten beide servers met dat heen-en-weer tot verzadiging. De connection strings van de applicatieserver bevatten No Reset On Close=true. Datasynchronisatie met andere systemen gebruikt tijdelijke tabellen, die pooling in transactiemodus niet bewaart, dus die heeft nog steeds een directe verbinding nodig.
• Databaseonderhoud: met duizenden databases spreidt een langere autovacuum_naptime de eigen bezoeken van PostgreSQL aan elke database.

Wat de cijfers niet dekken

• Cloudprocessors. Een virtuele processor in de cloud is meestal trager dan een kern van deze desktopprocessor.
• Het netwerk en de browser. Paginatijden bevatten niet het netwerk tussen de servers en je gebruikers, en ook niet de tijd die de browser nodig heeft om de pagina te tekenen.
• Zwaardere apps. Pagina's met meer gerelateerde lijsten, of grotere tabellen, kosten per pagina meer dan die van de test-app.
• Voorbij 10.000 mensen. Niets hier is geëxtrapoleerd voorbij een geteste grootte.

Waar dit naartoe gaat

Werkruimtes en hosting legt de keuze uit tussen één werkruimte per instantie en meerdere, en de twee manieren om de containers te draaien.