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

Démarrer l'API en mode profiling : pprof est exposé si ENABLE_PPROF=true
Exécuter un load test (k6 ou Go) sur les endpoints critiques
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.

2.2 KiB Raw Blame History