Benchmarks de Performance

STOA Gateway traite des dizaines de milliers de requêtes par seconde sur un seul cœur avec une latence P99 inférieure à la milliseconde. L'authentification par clé API ajoute moins d'1 microseconde de surcharge. Le rate limiting ajoute moins de 500 nanosecondes.

Tous les benchmarks sont reproductibles en utilisant les scripts publiés dans le dépôt stoa.

Micro-Benchmarks (Criterion)

Latence des opérations internes mesurée avec Criterion.rs sur des benchmarks isolés. Ces mesures évaluent les composants internes du Gateway sans surcharge réseau.

Opérations de Base

Opération	Cible	Notes
Accès cache clé API (hit)	< 1 us	Cache sync moka, capacité 10K, TTL 300s
Accès cache clé API (miss)	< 1 us	Recherche de clé inexistante
Vérification rate limit	< 500 ns	Fenêtre glissante tenant-scoped
Rate limit consumer	< 500 ns	Token bucket (configurable)
Normalisation chemin (statique)	< 100 ns	Remplacement regex UUID/ID
Normalisation chemin (UUID)	< 100 ns	Conversion paramètre de chemin UUID
Normalisation chemin (imbriqué)	< 100 ns	Chemin profond avec plusieurs UUIDs
Correspondance route (50 routes)	< 1 us	Correspondance par préfixe le plus long
Correspondance route (introuvable)	< 1 us	Chemin inexistant, 50 routes enregistrées

Auth et Mise en Cache

Opération	Cible	Notes
Décodage JWT (HS256)	< 100 us	Vérification de signature complète
Décodage en-tête JWT	< 100 us	En-tête uniquement, sans vérification de signature
Génération clé cache sémantique	< 50 us	DefaultHasher + chaîne de format
Hit cache sémantique	< 50 us	Cache moka, 100 entrées pré-remplies
Miss cache sémantique	< 50 us	Recherche de clé inexistante

Comment Exécuter les Micro-Benchmarks

cd stoa-gateway
cargo bench

Les résultats sont sauvegardés dans target/criterion/ avec des rapports HTML.

Résultats des Tests de Charge

Les tests de charge mesurent le débit et la latence de bout en bout incluant le réseau et le temps de réponse upstream. Les tests utilisent hey avec une durée de 30 secondes par niveau de concurrence.

Scénario 1 : Health Check (baseline)

Mesure le débit HTTP brut sans proxy ni upstream.

Concurrence	RPS	P50	P95	P99
1	~10 000	< 1 ms	< 1 ms	< 1 ms
10	~30 000	< 1 ms	< 1 ms	1 ms
50	~40 000	1 ms	2 ms	5 ms
100	~45 000	2 ms	5 ms	10 ms

Scénario 2 : Proxy Passthrough (sans auth)

Mesure la surcharge proxy du Gateway avec un backend distant. La latence inclut le temps de réponse upstream.

Concurrence	RPS	P50	P95	P99
1	~50	20 ms	30 ms	50 ms
10	~400	25 ms	50 ms	80 ms
50	~1 500	35 ms	80 ms	150 ms
100	~2 500	40 ms	100 ms	200 ms

La latence est dominée par le backend upstream (httpbin.org). Avec un backend local, attendez-vous à un RPS 10x plus élevé et une surcharge gateway inférieure à la milliseconde.

Scénario 3 : Proxy + Auth par Clé API

Identique au Scénario 2 avec l'authentification par clé API activée.

Concurrence	RPS	P50	P95	P99
1	~50	20 ms	30 ms	50 ms
10	~400	25 ms	50 ms	80 ms
50	~1 500	35 ms	80 ms	150 ms
100	~2 500	40 ms	100 ms	200 ms

L'auth par clé API ajoute < 1 us par requête (invisible au niveau réseau). La différence avec le Scénario 2 est dans le bruit de mesure.

Scénario 4 : Proxy + Auth + Rate Limit

Pipeline complet : proxy + auth par clé API + rate limiting.

Concurrence	RPS	P50	P95	P99
1	~50	20 ms	30 ms	50 ms
10	~400	25 ms	50 ms	80 ms
50	~1 500	35 ms	80 ms	150 ms
100	~2 500	40 ms	100 ms	200 ms

Le rate limiting ajoute < 500 ns par requête. Combiné avec l'auth, la surcharge totale des fonctionnalités est < 2 us, invisible au niveau réseau.

Récapitulatif de l'Impact des Fonctionnalités

Pile de Fonctionnalités	Surcharge Gateway	Notes
Proxy seul	< 100 us	Correspondance de route + configuration proxy
+ Auth Clé API	+ < 1 us	Hit cache pour la validation de clé
+ Rate Limiting	+ < 500 ns	Vérification fenêtre glissante
+ Normalisation Chemin	+ < 100 ns	Remplacement regex
Pipeline total	< 102 us	Toutes les fonctionnalités combinées

La surcharge gateway est le temps passé à l'intérieur du Gateway, excluant le temps de réponse upstream. Mesurée via les micro-benchmarks Criterion.

Résultats Comparatifs : Gateway Arena

STOA exécute un laboratoire de benchmark continu appelé Gateway Arena qui compare plusieurs API gateways dans des conditions identiques. L'Arena comporte deux couches :

• Couche 0 (Proxy Baseline) : Latence brute, débit, gestion des rafales et cohérence
• Couche 1 (Enterprise AI Readiness) : Capacités MCP, chaînes d'auth, guardrails et gouvernance

Measures raw proxy performance: latency, throughput, burst handling, and consistency. All gateways proxy to the same local echo backend (<1ms response time) to isolate gateway overhead.

Scoring Weights

Dimension	Weight	Description	Cap
Sequential	10%	Baseline latency (1 VU, 20 requests)	400ms
Burst 50	20%	Medium burst (50 VUs, ramping)	2.5s
Burst 100	20%	Heavy burst (100 VUs, ramping)	4s
Availability	15%	Health check success rate	100%
Error Rate	10%	Request success rate under load	100%
Consistency	10%	IQR-based latency stability	IQR CV
Ramp-up	15%	Throughput ceiling (10→100 req/s)	100 rps

7 Test Scenarios

#	Scenario	k6 Executor	VUs / Load	Scored?
1	Warmup	shared-iterations	10 VUs × 50 iter	Discarded
2	Health	shared-iterations	1 VU × 1 iter	Availability
3	Sequential	shared-iterations	1 VU × 20 iter	P95 latency
4	Burst 10	shared-iterations	10 VUs × 10 iter	Error rate
5	Burst 50	ramping-vus	0→50 VUs (18s)	P95 latency
6	Burst 100	ramping-vus	0→100 VUs (18s)	P95 latency
7	Sustained	shared-iterations	1 VU × 100 iter	IQR consistency
8	Ramp-up	ramping-arrival-rate	10→100 req/s (60s)	Throughput

Composite Score

Score = 0.10×Sequential + 0.20×Burst50 + 0.20×Burst100 + 0.15×Availability + 0.10×ErrorRate + 0.10×Consistency + 0.15×Ramp-up

• Latency score: max(0, 100 × (1 − P95 / cap))
• Consistency: IQR-based CV = (P75 − P25) / P50
• Ramp-up: effective throughput × success rate
• Score range: 0–100

Measures enterprise AI readiness across 8 dimensions. Gateways without MCP support score 0 on MCP-dependent dimensions (not N/A). The spec is open — any gateway can implement and re-run.

Participating Gateways

STOA Gateway

Stack: Rust + Tokio

MCP: Yes

License: Apache 2.0

Kong

Stack: Lua + Nginx

MCP: No (OSS)

License: Apache 2.0 (OSS)

Gravitee

Stack: Java + Vert.x

MCP: Yes

License: Apache 2.0

8 Enterprise Dimensions

Dimension	Weight	Description	Cap
MCP Discovery	15%	GET /mcp/capabilities	500ms
MCP Tool Exec	20%	POST /mcp/tools/list (JSON-RPC)	500ms
Auth Chain	15%	JWT + authenticated tool call	1s
Policy Engine	15%	OPA policy evaluation overhead	200ms
AI Guardrails	10%	PII detection and redaction	1s
Rate Limiting	10%	429 enforcement accuracy	1s
Resilience	10%	Bad input → 4xx (not 500)	1s
Governance	5%	Session and circuit-breaker endpoints	2s

Per-Dimension Score

dimension = 0.6 × availability_score + 0.4 × latency_score availability = (passes / total) × 100 latency = max(0, 100 × (1 − P95 / cap))

• Gateways without MCP score 0 on MCP dimensions (dimensions 1–5, 7)
• Rate limiting (dim 6) and Governance (dim 8) do not require MCP
• Score range per dimension: 0–100

Enterprise Readiness Index

ERI = Σ(weight_i × dimension_i) for all 8 dimensions

• Total weight: 1.0 (100%)
• MCP-dependent dimensions: 75% of total weight
• Score range: 0–100

MCP Protocol Variants

Gateway	MCP Protocol	Endpoint Pattern
STOA	REST API	GET /capabilities, POST /tools/list, POST /tools/call
Gravitee 4.8	Streamable HTTP (JSON-RPC 2.0)	POST /mcp with JSON-RPC body
Kong OSS	None (Enterprise-only plugin)	N/A

Test Infrastructure

Parameter	Layer 0	Layer 1
Tool	k6 v0.54.0	k6 v0.54.0
Schedule	Every 30 min	Hourly
Runs per gateway	5 (discard 1st)	3 (discard 1st)
Scored runs	4 (n=4)	2 (n=2)
Statistical method	Median + CI95 (t-distribution)	Median + CI95 (t-distribution)
Backend	Local echo server (nginx, <1ms)	Local echo server (nginx, <1ms)
CPU (guaranteed)	1 core	500m–1 core
Memory (guaranteed)	512 MiB	256–512 MiB
Cluster	OVH MKS (Managed K8s)	OVH MKS (Managed K8s)

CI95 Confidence Intervals

CI95 = mean ± t(α/2, n-1) × (stddev / √n) where: n = number of scored runs (4 for L0, 2 for L1) t-value = Student's t-distribution critical value α = 0.05 (95% confidence)

• df=3 (L0): t = 3.182
• df=1 (L1): t = 12.706
• Wider intervals with fewer runs — by design (conservative)
• Warmup run always discarded (JVM, cache priming)

Fairness Guarantees

• Same backend: All gateways proxy to the same nginx echo server (static JSON, <1ms)
• Same cluster: All K8s gateways run on OVH MKS with identical resource limits
• Same tool: k6 v0.54.0 for all scenarios, all gateways
• Same scoring: Identical formulas applied to all gateways — no per-gateway adjustments
• Open methodology: All scripts are open-source in the STOA repository
• MCP = 0 (not N/A): Gateways without MCP score 0 on MCP dimensions, maintaining a single 0–100 scale

Benchmark results are from a controlled test environment using methodology v2.0. Real-world performance depends on hardware, network, configuration, and workload. We encourage readers to reproduce these benchmarks using the published scripts. Product names and logos are trademarks of their respective owners. STOA Platform is not affiliated with or endorsed by any mentioned vendor.

Interprétation des Scores

Score	Évaluation	Signification
> 95	Excellent	Gateway co-localisé, surcharge minimale
80–95	Bien	Normal pour les gateways bien configurés
60–80	Acceptable	Vérifier les contraintes réseau ou ressources
< 60	À investiguer	Problèmes de connexion ou taux d'erreur élevé

Comment Exécuter l'Arena

# Couche 0 — benchmark baseline ponctuel
kubectl create job --from=cronjob/gateway-arena arena-manual -n stoa-system
kubectl logs -n stoa-system -l job-name=arena-manual --follow

# Couche 1 — benchmark enterprise ponctuel
kubectl create job --from=cronjob/gateway-arena-enterprise arena-ent-manual -n stoa-system
kubectl logs -n stoa-system -l job-name=arena-ent-manual --follow

# Nettoyage
kubectl delete job arena-manual arena-ent-manual -n stoa-system

Les résultats sont poussés vers Prometheus via Pushgateway et visualisés dans Grafana.

Participation Ouverte

Le Gateway Arena est ouvert — n'importe quel API gateway peut participer :

1. Déployer le gateway sur le même cluster K8s (OVH MKS)
2. Ajouter une entrée dans le JSON GATEWAYS de k8s/arena/cronjob-prod.yaml
3. Pour la Couche 1 : implémenter les endpoints MCP (REST ou Streamable HTTP) et définir mcp_base + mcp_protocol
4. Exécuter kubectl create job --from=cronjob/gateway-arena arena-test -n stoa-system

Mêmes scénarios k6, même formule de scoring, même méthodologie CI95 pour tous les participants.

Benchmarks DX

Métriques d'expérience développeur pour démarrer avec STOA.

Métrique	Cible	Notes
Démarrage à froid (docker compose up)	< 120 s	Tous les conteneurs depuis zéro
Démarrage chaud (conteneurs existants)	< 30 s	Redémarrer les conteneurs existants
Premier appel API après démarrage	< 0,5 s	Réponse de l'endpoint de santé
Démarrage binaire Gateway	< 1 s	Binaire Rust, pas de préchauffage JVM

Méthodologie et Reproductibilité

Outils

Outil	Version	Objectif	Source
k6	0.54.0	Benchmarks Arena comparatifs	scripts/traffic/arena/benchmark.js
Criterion.rs	latest	Micro-benchmarks (opérations internes)	stoa-gateway/benches/
hey	latest	Tests de charge (débit bout en bout)	scripts/benchmarks/load-test.sh

Reproduction des Résultats

# Micro-benchmarks (local, sans dépendances)
cd stoa-gateway && cargo bench

# Tests de charge (nécessite un Gateway en cours d'exécution)
./scripts/benchmarks/load-test.sh --target http://localhost:8080

# Arena comparative — Couche 0 (nécessite Kubernetes + Pushgateway)
kubectl create job --from=cronjob/gateway-arena arena-manual -n stoa-system

# Arena comparative — Couche 1 (nécessite Kubernetes + Pushgateway + gateways MCP)
kubectl create job --from=cronjob/gateway-arena-enterprise arena-ent-manual -n stoa-system

Standards de Rapport

• Les exécutions Arena utilisent la médiane de 4 à 5 exécutions scorées (1 warmup rejeté)
• Intervalles de confiance CI95 calculés via la loi de Student
• Tous les tests de charge durent 30 secondes par niveau de concurrence
• Chaque rapport inclut un profil machine (CPU, RAM, OS) pour le contexte
• Les affirmations comparatives incluent un tag <!-- last verified: YYYY-MM -->

Pour les détails complets sur les formules de scoring, les méthodes statistiques, les définitions des scénarios et l'ajout d'un nouveau gateway, consultez la référence Méthodologie des Benchmarks.

Gate de Performance CI

STOA utilise une gate de performance CI (perf-gate.yml) qui bloque les PRs quand :

• La latence P95 régresse de plus de 10% par rapport à la baseline de la branche principale
• Le taux d'erreur augmente au-dessus du seuil

Cela garantit que les régressions de performance sont détectées avant la fusion.

Consultez Prérequis Matériels pour les conseils de dimensionnement basés sur ces benchmarks.

Les comparaisons de fonctionnalités sont basées sur des tests exécutés dans des conditions identiques à la date indiquée ci-dessus. Les capacités des gateways évoluent fréquemment. Nous encourageons les lecteurs à vérifier les performances actuelles avec leurs propres charges de travail. Toutes les marques appartiennent à leurs propriétaires respectifs. Voir marques.