veza/veza-backend-api/scripts/loadtest/README.md

Load Tests - veza-backend-api

Installation

k6 (recommandé)

# 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)

# 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):

k6 run scripts/loadtest/k6_load_test.js

Avec URL personnalisée:

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):

AUTH_TOKEN=your_jwt_token BASE_URL=http://localhost:8080 k6 run scripts/loadtest/k6_load_test.js

Test upload endpoints (concurrent uploads et chunked uploads):

AUTH_TOKEN=your_jwt_token BASE_URL=http://localhost:8080 k6 run scripts/loadtest/k6_upload_load_test.js

Avec paramètres personnalisés pour uploads:

AUTH_TOKEN=your_jwt_token \
BASE_URL=http://localhost:8080 \
CHUNK_SIZE=2097152 \
TOTAL_CHUNKS=10 \
k6 run scripts/loadtest/k6_upload_load_test.js

Test plus intensif (modifier les stages dans le script):

stages: [
  { duration: '1m', target: 50 },  // 50 VUs
  { duration: '2m', target: 50 },
  { duration: '1m', target: 0 },
],

Vegeta Load Test (alternative)

Test simple:

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

Test multiple endpoints:

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)

Tests généraux (k6_load_test.js):

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

Tests upload (k6_upload_load_test.js):

• HTTP Request Duration:
  • P95 < 5000ms (uploads peuvent être plus lents)
  • P99 < 10000ms
• Error Rate: < 10% (uploads plus fragiles)
• Simple Upload Duration: P95 < 3000ms
• Chunked Upload Duration: P95 < 8000ms

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

Les scripts génèrent:

• stdout: Résumé textuel dans la console
• scripts/loadtest/k6_summary.json: Résultats détaillés en JSON (tests généraux)
• scripts/loadtest/k6_upload_summary.json: Résultats détaillés en JSON (tests upload)

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

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

Exemple GitLab CI

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

Tests de Performance Go

Les tests de performance Go sont disponibles dans tests/performance/upload_endpoints_performance_test.go.

Exécuter les tests de performance:

cd veza-backend-api
go test -tags=performance ./tests/performance -run TestPerformance -v

Exécuter les benchmarks:

cd veza-backend-api
go test -tags=performance ./tests/performance -bench=Benchmark -benchmem

Seuils de performance:

• Simple Upload: < 2s
• Chunked Upload Initiate: < 100ms
• Chunked Upload Chunk: < 200ms par chunk
• Chunked Upload Complete: < 3s
• Concurrent Uploads (10): < 10s total

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)
• Les tests d'upload nécessitent un token JWT valide (AUTH_TOKEN)
• Les tests d'upload créent des fichiers de test en mémoire
• Ajuster les seuils selon votre infrastructure (ex: latence réseau, CPU, etc.)