veza/docs/PERFORMANCE_BASELINE.md

78 lines
3.4 KiB
Markdown

# 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](../loadtests/README.md) pour l'exécution complète.
## Commande pprof
```bash
# 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
```bash
# 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](../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.