# Load Tests - veza-backend-api

## Installation

### k6 (recommandé)

```bash
# Linux
sudo gpg -k
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D9
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6

# macOS
brew install k6

# Windows
choco install k6
```

### Vegeta (alternative)

```bash
# Linux/macOS
go install github.com/tsenart/vegeta@latest

# Ou télécharger depuis https://github.com/tsenart/vegeta/releases
```

## Utilisation

### k6 Load Test

**Test basique** (endpoints critiques):
```bash
k6 run scripts/loadtest/k6_load_test.js
```

**Avec URL personnalisée**:
```bash
BASE_URL=http://staging.example.com:8080 k6 run scripts/loadtest/k6_load_test.js
```

**Avec token d'authentification** (pour tester endpoints protégés):
```bash
AUTH_TOKEN=your_jwt_token BASE_URL=http://localhost:8080 k6 run scripts/loadtest/k6_load_test.js
```

**Test plus intensif** (modifier les stages dans le script):
```javascript
stages: [
  { duration: '1m', target: 50 },  // 50 VUs
  { duration: '2m', target: 50 },
  { duration: '1m', target: 0 },
],
```

### Vegeta Load Test (alternative)

**Test simple**:
```bash
echo "GET http://localhost:8080/health" | vegeta attack -duration=30s -rate=10/s | vegeta report
```

**Test multiple endpoints**:
```bash
cat <<EOF | vegeta attack -duration=30s -rate=10/s | vegeta report
GET http://localhost:8080/health
GET http://localhost:8080/readyz
POST http://localhost:8080/api/v1/auth/login
Content-Type: application/json
{"email":"test@example.com","password":"test"}
EOF
```

## Seuils Attendus

### k6 Thresholds (définis dans le script)

- **HTTP Request Duration**: 
  - P95 < 500ms
  - P99 < 1s
- **Error Rate**: < 5%
- **Health Check Duration**: P95 < 100ms
- **Readyz Check Duration**: P95 < 200ms

### Interprétation

**✅ Test réussi**: Tous les seuils sont respectés
**⚠️ Test partiel**: Certains seuils dépassés (vérifier logs)
**❌ Test échoué**: Seuils critiques dépassés (investigation nécessaire)

## Résultats

### k6

Le script génère:
- **stdout**: Résumé textuel dans la console
- **scripts/loadtest/k6_summary.json**: Résultats détaillés en JSON

**Exemple de sortie**:
```
✓ health status is 200
✓ readyz status is 200
✓ login returns 401 or 400
✓ tracks returns 200 or 401

checks.........................: 100.00% ✓ 400      ✗ 0
data_received..................: 45 kB   1.5 kB/s
data_sent......................: 28 kB   933 B/s
http_req_duration..............: avg=45ms   min=12ms   med=38ms   max=250ms   p(95)=120ms   p(99)=180ms
http_reqs.....................: 100     3.3/s
```

### Vegeta

**Exemple de sortie**:
```
Requests      [total, rate, throughput]         100, 3.33, 3.30
Duration      [total, attack, wait]             30.1s, 30s, 100ms
Latencies     [min, mean, 50, 90, 95, 99, max]  12ms, 45ms, 38ms, 120ms, 150ms, 200ms, 250ms
Bytes In      [total, mean]                     45000, 450.00
Bytes Out     [total, mean]                     28000, 280.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:100
```

## Détection de Régressions

### Scénarios à surveiller

1. **Latence P95 > 500ms**: Performance dégradée
2. **Error rate > 5%**: Problèmes de stabilité
3. **Health check > 100ms**: Problème de base de données ou dépendances
4. **Readyz check > 200ms**: Problème de readiness

### Actions si seuils dépassés

1. **Vérifier logs application**: `tail -f /var/log/veza-backend-api/*.log`
2. **Vérifier métriques Prometheus**: 
   - `veza_db_pool_open_connections`
   - `veza_gin_http_request_duration_seconds`
   - `veza_gin_http_requests_total{status=~"5.."}`
3. **Vérifier ressources système**: `htop`, `iostat`, `netstat`
4. **Consulter runbooks**: `docs/runbooks/`

## Intégration CI/CD

### Exemple GitHub Actions

```yaml
- name: Run load tests
  run: |
    k6 run scripts/loadtest/k6_load_test.js
```

### Exemple GitLab CI

```yaml
load_test:
  script:
    - k6 run scripts/loadtest/k6_load_test.js
  only:
    - main
    - staging
```

## Notes

- Les tests utilisent des **credentials invalides** pour `/api/v1/auth/login` (attendu: 401)
- Les tests **ne modifient pas** de données (read-only sauf login qui échoue)
- Ajuster les **seuils** selon votre infrastructure (ex: latence réseau, CPU, etc.)