Detalles de rendimiento

RPC de páginas con caché · campaña iniciada el 2026-10-17 UTC

Resultados

Solicitudes correctas/s

7496 (intervalo 7033–7683)

Memoria de la API

32.8 MiB PSS

Tiempo de CPU de la API/solicitud

120 µs

Mediana de las latencias p95 / p99 por ensayo

5.10 / 6.38 ms

Carga de trabajo y entorno

Apple M1 Pro con macOS, una máquina virtual Linux ARM64 de Colima con ocho vCPU y un contenedor Debian para la API. Una vCPU para la API, cuatro para PostgreSQL y dos para wrk. El pool de la base de datos tenía ocho conexiones; wrk usó 32 conexiones HTTP.

La función SQL devolvía 100 filas de un conjunto de prueba de 10000 filas, 100 inquilinos y cargas útiles de 128 bytes. Cada solicitud enviaba un argumento JSON de 1 KiB. Se usaron HTTP en el frontend y conexiones PostgreSQL sin cifrar.

La verificación RS256 estaba activada, con caché de JWT y diez tokens reutilizados. La caché admitía 1000 entradas; pgxio también reservaba un presupuesto de 1 MiB para claims y resúmenes contabilizados, sin incluir los metadatos. La imagen con libpq experimental usó búferes copiados, no reenvío sin copias.

Método

Tres ensayos en orden aleatorio, cada uno con 10 segundos de calentamiento y 30 segundos de medición. El rendimiento es la mediana de solicitudes correctas por segundo. La memoria es la mediana de las medias por ensayo de la memoria proporcional (PSS) de los procesos de la API, excluyendo PostgreSQL. Las latencias son medianas de percentiles por ensayo, no percentiles agrupados.

Son mediciones locales en un host compartido. No establecen requisitos mínimos de RAM ni la capacidad del servidor completo. Los resultados con tokens repetidos en caché no representan cargas dominadas por tokens únicos.

Reproducibilidad

Descargar mediciones y procedencia (JSON)

Imagen de la API:

sha256:2daebd31eb22c698f232deb1d78d14939959c77dd126ff43eeeeb211c1f2bfcd

Imagen de PostgreSQL:

sha256:3645570cccdfa447589da9f57dd740faa29b30938e861289a5574b6ca6b03826