Dettagli del benchmark

RPC di pagine con cache · campagna avviata il 2026-10-17 UTC

Risultati

Richieste riuscite/s

7496 (intervallo 7033–7683)

Memoria API

32.8 MiB PSS

Tempo CPU API/richiesta

120 µs

Mediana delle latenze p95 / p99 delle prove

5.10 / 6.38 ms

Carico e ambiente

Apple M1 Pro con macOS, una VM Linux ARM64 Colima con otto vCPU e un container API Debian. Una vCPU per l'API, quattro per PostgreSQL e due per wrk. Il pool del database aveva otto connessioni; wrk usava 32 connessioni HTTP.

La funzione SQL restituiva 100 righe da dati di prova con 10000 righe, 100 tenant e payload di 128 byte. Ogni richiesta forniva un argomento JSON di 1 KiB. Sono stati usati HTTP per il frontend e connessioni PostgreSQL non cifrate.

La verifica RS256 era attiva, con cache JWT e dieci token riutilizzati. La cache consentiva 1000 voci; pgxio prevedeva anche 1 MiB per claim e digest contabilizzati, esclusi i metadati. L'immagine con libpq sperimentale usava buffer copiati, non inoltro senza copie.

Metodo

Tre prove in ordine casuale, ciascuna con 10 secondi di riscaldamento e 30 secondi di misura. Il throughput è la mediana delle richieste riuscite al secondo. La memoria è la mediana delle medie per prova della memoria proporzionale (PSS) dei processi API, escluso PostgreSQL. Le latenze sono mediane dei percentili per prova, non percentili aggregati.

Queste sono misurazioni locali su un host condiviso. Non stabiliscono requisiti minimi di RAM né la capacità dell'intero server. I risultati con token ripetuti in cache non rappresentano carichi dominati da token unici.

Riproducibilità

Scarica misurazioni e provenienza (JSON)

Immagine API:

sha256:2daebd31eb22c698f232deb1d78d14939959c77dd126ff43eeeeb211c1f2bfcd

Immagine PostgreSQL:

sha256:3645570cccdfa447589da9f57dd740faa29b30938e861289a5574b6ca6b03826