veza/docs/PERFORMANCE_BASELINE.md
senke ecf8d73e55
Some checks failed
Backend API CI / test-unit (push) Failing after 0s
Backend API CI / test-integration (push) Failing after 0s
Frontend CI / test (push) Failing after 0s
Storybook Audit / Build & audit Storybook (push) Failing after 0s
fix(release): v1.0.2 — Conformité complète V1_SIGNOFF (21 critères)
- Couverture Go: script coverage_report.sh, 39% mesuré
- Vitest thresholds frontend 50%
- Load test WebSocket: CHAT_ORIGIN→backend, WS_URL=/api/v1/ws
- Tests: chat_service (WSUrl), password_service (hash/expired)
- V1_SIGNOFF: 14 PASS, 7 N/A documentés
- PERFORMANCE_BASELINE, RGPD, PWA tables v1.0.2
- Runbooks, Grafana, Secrets validés
2026-03-03 21:18:53 +01:00

102 lines
4.2 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.
---
## 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
```bash
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 | | | | |