Test : load-test/dual-project.js
Durée : 35 minutes (5 min montée + 25 min plateau + 5 min descente)
VUs : 30 au total — 15 project1 (todos) + 15 project2 (inventaire JiiaCat)
Scénarios : 6 (p1_casual/active/power + p2_casual/active/power)
Objectif du test
Tous les tests précédents ne ciblaient que project1. La raison d’être du cluster est de servir deux piles Supabase isolées simultanément. Ce test devait répondre à trois questions :
- L’exécution des deux piles sous charge concurrente provoque-t-elle des interférences entre elles ?
- Le schéma plus complexe de project2 (requête JOIN + triggers INSERT/UPDATE pour les alertes) dégrade-t-il ses temps de réponse par rapport à project1 ?
- La RAM du VPS tient-elle avec 17 services tous sous charge concurrente ?
Résultat k6 : dépassement de seuil (exit 99)
Le test s’est exécuté jusqu’au bout. Le dépassement de seuil est le même artefact
géographique que tous les tests précédents : le seuil p(95)<500ms en lecture depuis la
zone de charge US de Grafana vers Francfort (~130 ms de RTT de référence). Aucune erreur
5xx, aucun redémarrage de service.
Mémoire VPS : les deux piles sous charge concurrente
| Service | Début | Fin | Delta | Limite | % en fin |
|---|---|---|---|---|---|
| project1_kong | 223 MB | 228 MB | +5 MB | 512 MB | 44,6% |
| project2_kong | 223 MB | 224 MB | +1 MB | 512 MB | 43,8% |
| project1_realtime | 165 MB | 165 MB | 0 MB | 512 MB | 32,3% |
| project2_realtime | 55 MB | 55 MB | 0 MB | 512 MB | 10,8% |
| project1_db | 75 MB | 78 MB | +3 MB | 1024 MB | 7,6% |
| project2_db | 49 MB | 50 MB | +1 MB | 1024 MB | 4,9% |
| project1_rest | 16 MB | 16 MB | 0 MB | 256 MB | 6,5% |
| project2_rest | 20 MB | 20 MB | 0 MB | 256 MB | 7,9% |
| project1_meta | 70 MB | 70 MB | 0 MB | 256 MB | 27,4% |
| project2_meta | 37 MB | 36 MB | -1 MB | 256 MB | 14,3% |
| project1_auth | 11 MB | 11 MB | 0 MB | 256 MB | 4,6% |
| project2_auth | 13 MB | 14 MB | +1 MB | 256 MB | 5,6% |
RAM hôte VPS : 2206–2224 MB utilisés sur 3819 MB. Stable tout au long du test — aucune pression.
Constats principaux
1. Aucune interférence entre les piles
Les deux piles ont tourné simultanément pendant 35 minutes sans s’affecter mutuellement. Les services de project1 ont affiché des profils CPU et mémoire identiques à ceux observés lorsque project2 était au repos. L’isolation par réseau overlay (project1_internal / project2_internal) a parfaitement tenu.
2. La croissance mémoire de Kong est proportionnelle à la charge
| Test | VUs par Kong | Croissance de Kong | Rythme |
|---|---|---|---|
| Endurance (project1 seul) | 30 | +23 MB sur 60 min | ~24 MB/h |
| Bi-projet (project1) | 15 | +5 MB sur 35 min | ~8,5 MB/h |
| Bi-projet (project2) | 15 | +1 MB sur 35 min | ~1,7 MB/h |
La croissance est proportionnelle au débit de requêtes, pas à la durée. Le profil de requêtes plus lourd de project2 entraîne moins de requêtes totales par VU (les JOIN et triggers prennent plus de temps → débit réduit), d’où une croissance plus faible.
3. PostgREST de project2 consomme légèrement plus de mémoire
project2_rest s’est stabilisé à 20 MB contre 16 MB pour project1_rest. Le schéma JiiaCat comporte 21 tables contre 1 seule pour project1 — PostgREST met en cache l’introspection du schéma au démarrage. C’est une différence de référence ponctuelle, pas un phénomène de croissance.
4. La DB de project2 est plus légère
project2_db est resté à 49–50 MB contre 75–80 MB pour project1_db. project1 a accumulé des données au fil des tests successifs ; la DB de project2 est plus récente. Les deux sont largement dans la limite de 1 Go.
5. Les BEAM VM de Realtime : parfaitement stables et isolées
Les deux services _realtime sont restés constants tout au long du test. project2_realtime
a une référence plus basse (55 MB contre 165 MB pour project1) car il a moins de
souscriptions CDC. Aucune croissance observée.
6. Empreinte totale du VPS sous charge concurrente bi-projet
Les deux piles actives + 15 VUs chacune : ~2,2 Go / 3,8 Go (58% de la RAM)
Les deux piles au repos : ~2,1 Go / 3,8 Go (55% de la RAM)
L’écart entre « au repos » et « les deux sous charge » est d’environ 100 MB répartis sur l’ensemble des services. Le cluster dispose d’environ 1,6 Go de marge même avec les deux projets actifs.
État des services après le test
Les 17 services à 1/1 réplicas. Zéro redémarrage sur les deux piles.
project1_* 8/8 services 1/1
project2_* 8/8 services 1/1
traefik 1/1
Synthèse
| Question | Réponse |
|---|---|
| Interférence entre les piles ? | Aucune détectée — piles entièrement isolées |
| project2 dégradé par un schéma complexe ? | Non — triggers et JOIN sans impact notable sur le VPS |
| RAM du VPS sous charge bi-projet ? | 58% utilisés — ~1,6 Go de marge restante |
| Fuites mémoire ? | Aucune — tous les services stables |
| OOM ou redémarrages ? | Aucun |
| Le CX22 peut-il servir les deux projets simultanément ? | Oui, confortablement |
| Un 3e projet tiendrait-il ? | Probablement — estimation ~2,5 Go utilisés avec 3 projets (65% de la RAM) |
Verdict cluster : prêt pour la production avec 2 projets concurrents. La marge mémoire suggère qu’un troisième projet est envisageable — le prochain test à mener serait une simulation triple-pile pour le confirmer.
Comparaison : profil de ressources project1 vs project2
| Métrique | project1 (todos) | project2 (JiiaCat) |
|---|---|---|
| Mémoire DB | 75–80 MB | 49–50 MB |
| Mémoire Rest (PostgREST) | 16 MB | 20 MB |
| Référence Realtime | 165 MB | 55 MB |
| Mémoire Kong | 223–228 MB | 223–224 MB |
| Mémoire Meta | 70 MB | 36–37 MB |
| Coût en écriture | Faible (INSERT simple) | Plus élevé (INSERT + trigger d’alerte) |
| Coût en lecture | Faible (table unique) | Plus élevé (JOIN sur 3 tables) |
project2 est plus léger sur la plupart des services car c’est un déploiement plus récent avec moins de données accumulées et moins de connexions de réplication CDC dans Realtime. Avec le temps et l’accumulation de données, son profil convergera vers celui de project1.