Dimensionering

De data plane is het onderdeel dat met het verkeer meegroeit: hij verwerkt elk verzoek, tekent het en legt het vast. De control plane doet het werk per overeenkomst en per levering, niet per verzoek. Daarom is alleen de data plane gemeten. Deze pagina geeft de cijfers en zegt eerlijk wat ze wel en niet zeggen.

Wat de data plane aankan

Gemeten is de kant van de datahouder: verzoeken die binnenkomen op /public, met een ondertekend verzoek en een vastgelegd bewijsblad per verzoek, doorgestuurd naar een backend die meteen antwoordt. Een trap telt als gehaald bij minder dan 1% fouten, een p99 onder 1 seconde en ten minste 95% van het gevraagde tempo.

	Data plane	Gehaald (p99 daar)	Maximaal verwerkt
Lezen	1 core	3000/s (43 ms)	3283/s
Lezen	2 cores	6000/s (125 ms)	6351/s
Sturen	1 core	3000/s (233 ms)	3000/s
Sturen	2 cores	4000/s (94 ms)	4943/s

Bij hetzelfde tempo gebruikt PostgreSQL ongeveer evenveel CPU als de data plane: bij 4000 leesverzoeken per seconde op 2 cores waren dat 2,4 cores voor de data plane en 2,5 voor PostgreSQL. Reken op 0,6 tot 0,85 ms CPU per verzoek voor de data plane, en ongeveer hetzelfde voor de database.

Het geheugen van de data plane bleef onder de 100 MiB zolang hij niet overbelast was. De PostgreSQL-container groeide met het tempo mee, van 0,5 GiB bij 1000 verzoeken per seconde tot 2,5 GiB bij 4000, de cache van het bestandssysteem meegerekend.

Hoe er gemeten is

• Machine: Hetzner ccx43 (AMD EPYC-Milan, 16 dedicated vCPU, 64 GB, lokale schijf met ext4). Een core is hier twee vCPU’s.
• Indeling: de data plane op 1 of 2 cores, PostgreSQL 17 op 2 cores, de backend (nginx) en de lastgenerator op eigen cores. Elk onderdeel had vaste CPU’s en een harde geheugengrens.
• Versie: de data plane van 1 oktober 2026, met tellers per minuut en het verzoekenlog op het standaardniveau warnings, en zonder groepjes van bewijsbladen (de standaard). Dat is een versie van vóór 0.2. Versie 0.2 controleert per verzoek ook het gebouw en de punten uit de overeenkomst; dat is niet apart gemeten.
• Herhalingen: de tabel hierboven is één reeks met trappen van 20 seconden. Een eerdere referentiemeting met twee herhalingen en trappen van 60 seconden gaf op 1 core 2000 tot 3000 per seconde, en op 2 cores 4000 per seconde, bij lezen en bij sturen. Verschillen van één trap tussen herhalingen zijn normaal.

Wat niet is gemeten:

• je eigen backend: in de test antwoordde nginx meteen; een echt BMS is bijna altijd trager dan de data plane;
• de gateway van een dataontvanger, de control plane, de TLS-proxy en het netwerk tussen deelnemers;
• sleutels in een HSM of Vault: de test tekende met een sleutel uit een bestand. Met pkcs11 of vault tekent de data plane elk antwoord via de KMS, en dat kost per verzoek een aanroep.

Wat dat betekent voor een installatie

• De data plane: 1 core is ruim genoeg voor duizenden verzoeken per seconde. Geef hem 2 cores als je die verwacht, of als je ruimte wilt voor pieken. Er is precies één actieve data plane per deelnemer; meer doorvoer haal je met meer cores en een snellere database, niet met meer instances.
• PostgreSQL: geef de database minstens evenveel CPU als de data plane, en een snelle schijf. Elk verzoek wacht op een paar commits. Op een trage schijf of netwerkopslag helpt BL_EVIDENCE_WRITERS=32: de data plane legt bewijsbladen dan in groepjes vast. Op een laptop verdubbelde dat de doorvoer. Op de snelle lokale schijf van de meetmachine gaf het vlak bij de grens 12 tot 25% meer doorvoer, maar daaronder een hogere latency en meer CPU voor PostgreSQL. Daarom staat het standaard uit.
• Verbindingen: de data plane gebruikt standaard een pool van 50 databaseverbindingen, de control plane 10 per replica en de gebouwservice 5 (BL_DB_MAX_CONNECTIONS). Elke instance houdt daarnaast een of twee verbindingen buiten de pool open. Zet max_connections van PostgreSQL ruim hoger dan de som.
• Open bestanden: elke verbinding is een open bestand. De data plane hoogt bij het starten zijn limiet op tot de harde limiet van het proces; zorg dat die hoog genoeg is.
• De control plane en de gebouwservice zijn niet gemeten. Ze werken per overeenkomst, levering en beheerhandeling, niet per verzoek van een app. Meet ze in je acceptatieomgeving.

Hoe groot de database wordt

Het bewijs bepaalt de omvang. De data plane legt elk verzoek vast als een bewijsblad, met de handtekeningen van beide kanten.

• De eerste 90 dagen (BL_EVIDENCE_HOT_DAYS) staat een blad volledig in PostgreSQL: gemeten ongeveer 3,5 tot 3,7 kB per leesverzoek en 4,5 tot 4,8 kB per schrijfverzoek, indexen meegerekend.
• Daarna comprimeert de data plane de bladen per venster, in dezelfde database. Er blijven de hashes over, zodat elk bewijs blijft kloppen, en het gecomprimeerde blok. Dat is niet gemeten; we schatten het op ruwweg 1 kB per verzoek.
• Na de bewaartermijn (BL_EVIDENCE_RETENTION_YEARS, minimaal 5 jaar in productie en acceptatie) gaan de bladen weg. De keten zelf, met de wortel van elk venster, blijft.

Gemiddeld tempo	Per dag	Na 90 dagen	Na 5 jaar
1 verzoek/s	0,3 GB	~30 GB	~180 GB
10 verzoeken/s	3 GB	~300 GB	~1,8 TB

Dit zijn schattingen voor leesverzoeken, uit de metingen afgeleid; reken met een marge. De tellers per minuut voor de schermen zijn klein en verdwijnen na 90 dagen (BL_REQUEST_COUNTS_DAYS). Het verzoekenlog staat niet in de database maar in je logopslag: op niveau all ongeveer 320 bytes per verzoek, vóór compressie.

TechnischDe rapporten

De cijfers komen uit de belastingtest bl-bench, die één onderdeel in het echte image meet met vaste CPU’s en een harde geheugengrens; het harnas speelt alles eromheen. De rapporten staan in de repository onder docs/bench/. De meting met de tabel hierboven is die van 1 oktober 2026 met tellers en het verzoekenlog; de referentiemeting met twee herhalingen is die van dezelfde dag op commit 91c5969.