Résultats de performance, quotas, RTO et RPO mesurés
Exigences : OBSE-013, OBSE-014, LLM_-009, RELE-014, OBSE-010. English version: en/performance-results.md.
Chaque chiffre de cette page provient d'une exécution de bash tools/perf/run.sh sur l'hôte décrit ci-dessous, le 2026-10-30 (dossier de résultats /tmp/eai-perf-final). Rien n'est estimé. Les chiffres dépendent de l'hôte (WSL2 partagé avec d'autres processus) : ils servent de référence de capacité locale, pas d'engagement de service.
Hôte
nproc: 6
uname -sr: Linux 6.6.87.2-microsoft-standard-WSL2
free -g:
total used free shared buff/cache available
Mem: 47 20 3 0 23 26
Swap: 96 1 94
Commandes
bash tools/perf/run.sh /tmp/eai-perf-final
cd services/control-plane && .venv/bin/python -m pytest -q tests/test_perf_measurements.py tests/test_finops_attribution.py tests/test_lineage_exploration.py
tools/perf/loadgen.py (Python asyncio et httpx, aucun autre outil) démarre sur des ports libres un PostgreSQL jetable (pgserver de services/control-plane/.venv, toutes les migrations appliquées), le faux fournisseur compatible OpenAI tools/perf/fake_upstream.py et le Control Plane sous uvicorn (un processus, EAI_AUTH_DEV=1, EAI_EGRESS_PRIVATE_ALLOWLIST=127.0.0.1/32, limitation de débit globale désactivée pour mesurer la plateforme et non le limiteur). Le temps CPU (utime + stime) et la RSS du processus API sont lus dans /proc/<pid>/stat et /proc/<pid>/status. Les résultats sont écrits dans load.json et load.md. tools/perf/resilience.py produit resilience.json.
Les scripts k6 de deploy/loadtest n'ont pas été exécutés : le binaire k6 est sous AGPL-3.0 et ne peut servir qu'en outil de test local jamais distribué ; le générateur maison est utilisé à la place.
Débit et latence (OBSE-014)
400 requêtes par niveau de concurrence après 4 requêtes de chauffe. Scénarios : health (GET /healthz), model_gateway_chat (POST /v1/gateway/chat/completions vers le faux fournisseur : réservation de quota, PEP, DLP, appel, Usage Event, commit), tool_gateway_invoke (POST /v1/tools/{name}/invoke sur le gestionnaire intégré echo : le garde de sortie refuse par conception les destinations privées pour les outils des tenants, le chemin mesuré est donc la passerelle d'outils complète sans saut réseau). La colonne CPU est le temps CPU consommé par l'API pendant le niveau ; la RSS est celle de fin de niveau.
| Scénario | Concurrence | Requêtes | Erreurs | Taux d'erreur | Débit (req/s) | p50 (ms) | p95 (ms) | p99 (ms) | CPU API (s) | RSS API (Mio) |
|---|---|---|---|---|---|---|---|---|---|---|
| health | 1 | 400 | 0 | 0.000 | 368.13 | 2.6 | 3.37 | 4.47 | 0.77 | 127.7 |
| health | 8 | 400 | 0 | 0.000 | 502.51 | 14.57 | 19.93 | 82.08 | 0.74 | 128.3 |
| health | 32 | 400 | 0 | 0.000 | 421.47 | 54.79 | 213.32 | 299.12 | 0.73 | 130.2 |
| model_gateway_chat | 1 | 400 | 0 | 0.000 | 13.09 | 73.92 | 91.92 | 110.68 | 22.43 | 209.7 |
| model_gateway_chat | 8 | 400 | 0 | 0.000 | 19.9 | 397.87 | 523.22 | 565.42 | 34.52 | 222.3 |
| model_gateway_chat | 32 | 400 | 0 | 0.000 | 20.4 | 1548.02 | 1960.26 | 2147.06 | 50.18 | 261.3 |
| tool_gateway_invoke | 1 | 400 | 0 | 0.000 | 34.56 | 25.65 | 46.71 | 66.93 | 6.16 | 261.2 |
| tool_gateway_invoke | 8 | 400 | 0 | 0.000 | 46.96 | 163.84 | 244.77 | 302.09 | 7.61 | 261.2 |
| tool_gateway_invoke | 32 | 400 | 0 | 0.000 | 42.2 | 727.72 | 938.55 | 1039.71 | 9.25 | 261.5 |
Lecture : un seul processus uvicorn plafonne vers 20 appels de passerelle de modèle par seconde sur cet hôte ; au delà, la concurrence n'ajoute que de l'attente (la latence croît linéairement). La montée en charge passe par plusieurs réplicas, non mesurée ici (voir les éléments bloqués).
Quotas (LLM_-009)
| Limite | Configuration | Réponses observées | Code d'erreur | Reprise |
|---|---|---|---|---|
| Requêtes par minute | manifeste d'outil rate_limit.requests_per_minute: 5 | 5 x 200 puis 3 x 429, Retry-After: 60 | rate_limited | 200 de nouveau 60.6 s après le premier refus (fenêtre glissante de 60 s) |
| Jetons | POST /v1/quotas tenant, period: hour, limit_tokens: 100 | 4 x 200 (96 jetons consommés) puis 429 avant tout appel fournisseur | quota_exceeded | 200 dès que la limite est relevée par PUT /v1/quotas/{id} |
| Réservations simultanées | POST /v1/quotas tenant, period: day, limit_cost: 0.30, réservations de 0.10 via POST /v1/quotas/reserve | 3 x 201 puis 2 x 429 | quota_exceeded | 201 dès la libération (POST /v1/quotas/{id}/release) |
Le service de quotas ne propose pas de période inférieure à l'heure (request, run, hour, day, month) : la limite de jetons par minute n'existe pas en tant que telle, la limite la plus fine mesurée est la limite horaire. La reprise de la limite horaire après expiration de la fenêtre (une heure) n'a pas été attendue ; la reprise a été mesurée par relèvement de la limite.
Attribution des coûts (OBSE-013) et lignage (OBSE-010)
Les identifiants de tenant ne sont volontairement pas des labels Prometheus (cardinalité et isolation). L'attribution par tenant, modèle et agent est prouvée par services/control-plane/tests/test_finops_attribution.py via GET /v1/finops/usage, GET /v1/finops/summary?group_by=model|agent|tenant et les lignes de l'export analytique vers ClickHouse, sans fuite entre tenants. Le parcours de lignage réponse vers source et retour est prouvé par services/control-plane/tests/test_lineage_exploration.py.
RTO et RPO (RELE-014)
Objectifs RTO et RPO : à fixer par le client. Seules les valeurs mesurées figurent ici.
| Composant | Mesure | Valeur mesurée |
|---|---|---|
| PostgreSQL | taille de la base (migrations + 50 090 lignes de sonde) | 18 706 915 octets |
| PostgreSQL | sauvegarde scripts/pg_backup.sh (format custom, vérifiée par pg_restore --list) | 0.16 s, 816 324 octets |
| PostgreSQL | restauration scripts/pg_restore.sh dans une base vide, avec contrôle des migrations | 9.059 s |
| PostgreSQL | perte de données d'une sauvegarde logique (écritures toutes les 10 ms) | 50 lignes, fenêtre de 0.636 s écrite après l'instantané |
| Redis | promotion du réplica (REPLICAOF NO ONE) après SIGKILL du primaire, jusqu'à la première écriture acceptée | 4.071 s |
| Redis | clés acquittées par le primaire et absentes du réplica promu | 0 sur 350 |
La perte d'une sauvegarde logique est tout ce qui est écrit après l'instantané : le RPO réel d'une restauration est donc l'intervalle entre deux sauvegardes, plus cette fenêtre. Le temps de promotion Redis est mesuré du SIGKILL jusqu'à la première écriture acceptée par le réplica promu, la détection de panne par Sentinel ou l'opérateur n'est pas incluse. Un premier essai le même jour a donné 2.907 s de restauration et 0.0021 s de promotion : la variance de l'hôte partagé est forte, ces valeurs ne sont pas des bornes.
Éléments bloqués
- Mesures GPU : BLOQUÉ, aucun GPU sur cet hôte.
- Haute disponibilité et montée en charge en cluster (plusieurs réplicas, PostgreSQL CloudNativePG, Redis Sentinel) : BLOQUÉ, aucun cluster disponible ; rien n'a été appliqué sur un cluster ou un compte cloud.