Benchmark-Details

Seiten-RPC mit Cache · Messkampagne gestartet am 2026-10-17 UTC

Ergebnisse

Erfolgreiche Anfragen/s

7496 (Spanne 7033–7683)

API-Speicher

32.8 MiB PSS

API-CPU-Zeit/Anfrage

120 µs

Median der p95-/p99-Latenzen der Läufe

5.10 / 6.38 ms

Lastprofil und Umgebung

Apple M1 Pro mit macOS, einer ARM64-Colima-Linux-VM mit acht vCPUs und einem Debian-API-Container. Eine vCPU für die API, vier für PostgreSQL und zwei für wrk. Der Datenbankpool hatte acht Verbindungen; wrk nutzte 32 HTTP-Verbindungen.

Die SQL-Funktion lieferte 100 Zeilen aus Testdaten mit 10000 Zeilen, 100 Mandanten und 128-Byte-Nutzlasten. Jede Anfrage enthielt ein JSON-Argument von 1 KiB. Verwendet wurden HTTP am Frontend und unverschlüsselte PostgreSQL-Verbindungen.

RS256-Verifikation war mit JWT-Cache und zehn wiederverwendeten Tokens aktiviert. Der Cache erlaubte 1000 Einträge; pgxio budgetierte zusätzlich 1 MiB für erfasste Claims und Digests, ohne Metadaten-Overhead. Das Image mit experimentellem libpq verwendete kopierte Puffer, keine Weiterleitung ohne Kopieren.

Methode

Drei randomisierte Läufe mit je 10 Sekunden Aufwärmphase und 30 Sekunden Messung. Durchsatz ist der Median erfolgreicher Anfragen pro Sekunde. Speicher ist der Median der mittleren proportionalen Speicherbelegung (PSS) der API-Prozesse je Lauf, ohne PostgreSQL. Latenzen sind Mediane der Perzentile einzelner Läufe, keine zusammengefassten Perzentile.

Dies sind lokale Messungen auf einem gemeinsam genutzten Host. Sie belegen weder Mindest-RAM-Anforderungen noch die Kapazität des gesamten Servers. Ergebnisse mit wiederverwendeten Tokens im Cache repräsentieren keine Lastprofile mit überwiegend unterschiedlichen Tokens.

Reproduzierbarkeit

Messungen und Herkunftsnachweise herunterladen (JSON)

API-Image:

sha256:2daebd31eb22c698f232deb1d78d14939959c77dd126ff43eeeeb211c1f2bfcd

PostgreSQL-Image:

sha256:3645570cccdfa447589da9f57dd740faa29b30938e861289a5574b6ca6b03826