veza/docs/PERFORMANCE_BASELINE.md

Performance Baseline — Veza API

Version : v0.951 Objectif : Documenter les latences P50/P95/P99 des endpoints critiques pour détecter les régressions.

Méthodologie

1. Démarrer l'API en mode profiling : pprof est exposé si ENABLE_PPROF=true
2. Exécuter un load test (k6 ou Go) sur les endpoints critiques
3. Mesurer latences via Prometheus (http_request_duration_seconds) ou pprof

Endpoints critiques à monitorer

Endpoint	Méthode	Description
/api/v1/auth/login	POST	Login utilisateur
/api/v1/auth/register	POST	Inscription
/api/v1/tracks	GET	Liste des tracks (cursor pagination v0.931)
/api/v1/tracks/search	GET	Recherche
/api/v1/users/me	GET	Profil utilisateur
/api/v1/marketplace/orders	POST	Création commande
/api/v1/notifications	GET	Notifications
/api/v1/conversations	GET	Conversations
/api/v1/analytics/me	GET	Analytics
/health	GET	Health check

Cibles v1.0 (v0.951)

• P99 < 500ms sur tous les endpoints critiques à 500 req/s (stress_500rps.js)
• 1000 WebSocket : connexions stables 5 min, taux livraison > 99% (stress_1000ws.js)
• 50 uploads concurrents : tous réussis, backpressure respecté (uploads.js)
• GET /tracks : pagination cursor-based (v0.931) garantit des performances constantes quelle que soit la page

Scripts k6 v0.951

Script	Commande	Seuils
API stress 500 VUs	k6 run loadtests/backend/stress_500rps.js	P99 < 500ms (login, tracks, search, products)
WebSocket 1000	k6 run loadtests/chat/stress_1000ws.js	ws_connection_failures < 1%, ws_message_failures < 1%
Uploads 50	k6 run loadtests/backend/uploads.js	P95 < 5s (simple), P95 < 8s (chunked)

Voir loadtests/README.md pour l'exécution complète.

Commande pprof

# Profiler 30s pendant un load test
go tool pprof -http=:8081 http://localhost:8080/debug/pprof/profile?seconds=30

Métriques Prometheus

Les middlewares de monitoring exposent http_request_duration_seconds avec les labels method, path, status. Utiliser des histogram quantiles pour P50/P95/P99.

Lighthouse v0.982 (Frontend)

Objectif : Performance ≥ 90, Accessibility ≥ 90, Best Practices ≥ 90 sur les pages critiques.

Pages à auditer

Page	Route	Cible Performance	Cible Accessibility
Login	/login	≥ 90	≥ 90
Dashboard	/dashboard	≥ 90	≥ 90
Tracks	/library ou /tracks	≥ 90	≥ 90
Marketplace	/marketplace	≥ 90	≥ 90
Search	/search	≥ 90	≥ 90
Profile	/profile	≥ 90	≥ 90

Procédure d'audit

# Prérequis: app frontend en cours d'exécution (npm run dev ou build + preview)
npx lighthouse http://localhost:4173/ --view --output=html --output-path=./lighthouse-reports/home.html
npx lighthouse http://localhost:4173/login --view --output=html --output-path=./lighthouse-reports/login.html
# Répéter pour chaque page critique

Dernier audit

Voir config/incus/LIGHTHOUSE_AUDIT_REPORT.md pour le dernier rapport (2026-01-15). Accessibility 93, Best Practices 96 — objectif v0.982 atteint sur ces critères. Performance à revalider après corrections NO_LCP.

---

Résultats v1.0.2

Prérequis : docker compose up -d, backend + PostgreSQL + Redis.

Load tests corrigés (v0.502)

• WebSocket load test : CHAT_ORIGIN pointant vers backend ws://localhost:8080, WS_URL = /api/v1/ws
• Fichiers : loadtests/config.js, loadtests/chat/stress_1000ws.js, loadtests/chat/websocket.js

Commandes pour exécution

k6 run loadtests/backend/stress_500rps.js      # 500 req/s, P99 < 500ms
k6 run loadtests/chat/stress_1000ws.js        # 1000 WebSocket, < 1% échec
k6 run loadtests/backend/uploads.js            # 50 uploads

Tableau résultats (à remplir après exécution sur infra)

Endpoint / Script	P50	P95	P99	Taux échec
stress_500rps (login, tracks, search)
stress_1000ws
uploads