Résumé de l’implémentation : Rate Limiting Configurable
Date : 2025-10-24
Problème résolu
Le rate limiting de l’API (100 requêtes/minute par IP) faussait les résultats des tests de charge, rendant impossible la mesure des vraies performances du système.
Solution
Rate limiting désormais configurable via variable d’environnement ENABLE_RATE_LIMITING.
Fichiers créés
Fichier |
Description |
|---|---|
|
Configuration optimisée pour load tests (rate limiting OFF) |
|
Docker Compose standalone pour tests de charge |
|
Script helper pour activer/désactiver facilement |
|
Documentation complète de la solution |
|
Changelog détaillé des modifications |
|
Ce fichier (résumé) |
Fichiers modifiés
Fichier |
Modification |
|---|---|
|
Ajout de |
|
Documentation de la nouvelle variable |
|
Section rate limiting + Quick Start |
|
Avertissement rate limiting en haut |
|
Section rate limiting |
|
Commentaires explicatifs |
Utilisation rapide
Tests locaux (Recommandé)
cd load-tests
docker compose -f docker-compose.loadtest.yml up -d
export BASE_URL=http://localhost:8080
./scripts/light-load.sh
docker compose -f docker-compose.loadtest.yml down
Tests production (VPS)
# Désactiver
./toggle-rate-limiting.sh off
docker compose restart backend
# Tester
export BASE_URL=https://api.votredomaine.com
./scripts/remote-medium-load.sh
# RÉACTIVER !
./toggle-rate-limiting.sh on
docker compose restart backend
Vérification
# Vérifier le status
docker compose -f docker-compose.loadtest.yml logs backend | grep "Rate limiting"
# Devrait afficher : "Rate limiting enabled: false"
Sécurité
Default : Rate limiting ACTIVÉ (true)
Production : TOUJOURS activé
Load tests : Temporairement désactivé
Impact
Avant
Throughput plafonné à ~100 req après burst
Impossible de tester au-delà de 1.67 req/s
Résultats faussés par le throttling
Après
Throughput limité uniquement par hardware (CPU/DB/réseau)
Tests de charge significatifs
Mesure des vraies performances du système
Code principal
// backend/src/main.rs:32-37
let enable_rate_limiting = env::var("ENABLE_RATE_LIMITING")
.unwrap_or_else(|_| "true".to_string())
.to_lowercase()
.parse::<bool>()
.unwrap_or(true);
// backend/src/main.rs:128-134
let mut app = App::new().app_data(app_state.clone());
if enable_rate_limiting {
app = app.wrap(Governor::new(&governor_conf));
}
app.wrap(cors).wrap(middleware::Logger::default()).configure(configure_routes)
Configuration
# backend/.env.loadtest
ENABLE_RATE_LIMITING=false
RUST_LOG=error
ACTIX_WORKERS=4
DB_POOL_MAX_CONNECTIONS=20
Documentation
Solution complète :
RATE_LIMITING_SOLUTION.mdChangelog :
CHANGELOG_RATE_LIMITING.mdQuick Start :
START_HERE.mdREADME :
README.md
Tests recommandés
Tester avec rate limiting désactivé
Comparer les résultats avant/après
Identifier les vraies limites du système (CPU, DB, réseau)
Optimiser en conséquence
Next Steps
✅ Implémenter la solution (FAIT)
⏭️ Lancer les tests de charge sans rate limiting
⏭️ Documenter les performances réelles
⏭️ Ajuster les ressources si nécessaire (workers, DB pool)
⏭️ Réoptimiser la configuration pour production
Commandes utiles
# Status
./toggle-rate-limiting.sh status
# Démarrer env de test
docker compose -f docker-compose.loadtest.yml up -d
# Logs
docker compose -f docker-compose.loadtest.yml logs -f backend
# Nettoyer
docker compose -f docker-compose.loadtest.yml down -v
# Lancer tous les tests
./run-all-tests.sh
Points d’attention
⚠️ Ne jamais oublier de réactiver le rate limiting après les tests !
⚠️ Traefik a aussi un rate limiting (100 req/s) dans docker-compose.vps.yml
⚠️ Tests en production : Faire en heures creuses, réactiver immédiatement après
✅ Tests locaux : Utiliser docker-compose.loadtest.yml (plus sûr)
Support
Pour toute question ou problème :
Consulter
RATE_LIMITING_SOLUTION.mdVérifier les logs :
docker compose logs backendTester le status :
./toggle-rate-limiting.sh status