Test : load-test/triple-project.js Durée : 35 minutes (5 min montée + 25 min plateau + 5 min descente) VUs : 30 au total — 10 par projet (7 casual + 2 active + 1 power) Scénarios : 9 (p1/p2/p3 × casual/active/power)


Objectif du test

Le test bi-projet avait confirmé que le CX22 gère confortablement 2 piles concurrentes à 58 % de RAM. Ce test visait à répondre aux questions restantes :

  1. Le CX22 peut-il soutenir 3 projets Supabase concurrents sous charge réaliste ?
  2. La RAM du VPS tient-elle avec 25 services tous sollicités simultanément ?
  3. Y a-t-il des interférences entre piles à 3 instances ?

Le project3 a été provisionné comme une pile neuve avec la même version de Supabase que project1/project2, avec un schéma todos (JiiaCat pas encore migré). Ce test valide l’isolation des piles, pas la complexité du schéma.


Résultat k6 : dépassement de seuil (exit 99)

Le test s’est exécuté jusqu’au bout. Même artefact géographique que tous les tests précédents : le seuil p(95)<500ms sur les lectures provient de 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 : trois piles sous charge concurrente

ServiceDébutFinPicLimitePic%
project1_kong226 MB229 MB229 MB512 MB44,7%
project2_kong227 MB228 MB228 MB512 MB44,5%
project3_kong218 MB227 MB227 MB512 MB44,3%
project1_realtime73 MB69 MB73 MB512 MB14,3%
project2_realtime26 MB26 MB26 MB512 MB5,1%
project3_realtime163 MB164 MB164 MB512 MB32,0%
project1_db39 MB38 MB43 MB1024 MB4,2%
project2_db25 MB28 MB30 MB1024 MB2,9%
project3_db82 MB84 MB93 MB1024 MB9,1%
project1_rest16 MB15 MB16 MB256 MB6,2%
project2_rest24 MB24 MB24 MB256 MB9,4%
project3_rest9 MB14 MB14 MB256 MB5,5%
project1_meta50 MB48 MB50 MB256 MB19,5%
project2_meta18 MB18 MB18 MB256 MB7,0%
project3_meta75 MB75 MB76 MB256 MB29,7%
project1_studio146 MB146 MB147 MB512 MB28,7%
project2_studio31 MB37 MB37 MB512 MB7,2%
project3_studio162 MB147 MB164 MB512 MB32,0%

RAM hôte VPS : 2433–2654 MB utilisés sur 3819 MB (64–70 % de RAM) pendant le test.


Constats principaux

1. Aucune interférence entre piles — trois instances parfaitement isolées

Les 25 services ont tourné pendant 35 minutes sous charge simultanée sans interférence CPU ni mémoire. Chaque projet affichait les mêmes profils d’utilisation que lorsque les deux autres étaient au repos.

2. RAM du VPS confortablement dans le budget à 3 piles

Trois piles actives + 10 VUs chacune :  2433–2654 MB / 3819 MB  (64–70%)
Deux piles actives + 15 VUs chacune :   ~2200–2224 MB / 3819 MB  (58%)
Une pile au repos (référence) :          ~2100 MB / 3819 MB       (55%)

Le coût RAM incrémental d’un troisième projet sous charge est de ~400–450 MB (même ordre de grandeur que l’ajout d’un deuxième projet). Le CX22 conserve ~1,2 Go de marge avec les trois piles sous charge.

3. Mémoire Kong : stable sur les trois piles

Les trois Kong ont démarré entre 218 et 227 MB et terminé entre 227 et 229 MB — une croissance de ~1–9 MB sur 35 minutes. C’est cohérent avec les tests précédents (croissance proportionnelle au débit de requêtes). Aucune divergence entre les piles.

4. Les références Realtime BEAM révèlent la maturité de la pile

PileRéférence RealtimeExplication
project173 MBPile ancienne — plus d’historique CDC
project226 MBÂge intermédiaire
project3163–164 MBPile neuve dont le Realtime a été réinitialisé plusieurs fois pendant le provisionnement — mémoire BEAM supplémentaire pour les tables internes

La référence de project3_realtime est plus élevée qu’attendu pour une pile neuve. Le conteneur a été redémarré de force plusieurs fois pendant la séquence d’initialisation de Realtime (correction du jwt_secret, renommage du tenant). La BEAM VM conserve l’état des processus des exécutions précédentes dans ses structures en mémoire. Cette valeur devrait se stabiliser à un niveau inférieur après un cycle de redémarrage propre.

5. project3_db au plus haut à 93 MB en pic

project3 a accumulé des données en base pendant le setup() (création utilisateur + création de la table todos) et pendant les 35 minutes de test. Le pic à 93 MB reste largement dans la limite de 1 Go (9,1 %).

6. Les 25 services stables — zéro redémarrage

project1_*   8/8 services  1/1
project2_*   8/8 services  1/1
project3_*   8/8 services  1/1
traefik               1/1

État des services après le test

Les 25 services à 1/1 réplicas. Zéro redémarrage sur les trois piles.


Synthèse

QuestionRéponse
3 piles sous charge concurrente — RAM ?64–70 % utilisés — ~1,2 Go de marge
Interférences entre piles ?Aucune — toutes les piles parfaitement isolées
OOM ou redémarrages ?Aucun
Fuites mémoire ?Aucune — tous les services stables
Le CX22 peut-il servir 3 projets simultanément ?Oui, confortablement
Un 4e projet tiendrait-il ?Probable — est. ~3,0–3,1 Go à 4 piles (~80 % de RAM)

Verdict cluster : prêt pour la production avec 3 projets concurrents. La marge mémoire suggère qu’un 4e projet est envisageable mais pousserait vers 80 % d’utilisation RAM — le seuil recommandé pour passer à la taille supérieure. Un passage au CX32 (8 Go de RAM) offrirait une marge confortable pour 5 à 6+ projets.


Projection de capacité

ProjetsRAM est. utilisée% du CX22% du CX32
1~2,1 Go55%26%
2~2,2 Go58%28%
3~2,6 Go68%33%
4 (projeté)~3,0 Go79%38%
Seuil de migration CX223,1 Go81%

Chaque projet supplémentaire ajoute ~350–450 MB de RAM au repos sous charge légère. Le cluster peut héberger confortablement 3 projets sur CX22. À 4 projets, un redimensionnement vers le CX32 devient conseillé.


Comparaison : profil de ressources de tous les projets

Serviceproject1project2project3
DB memory39–43 MB25–30 MB82–93 MB
Rest (PostgREST)15–16 MB24 MB9–14 MB
Realtime69–73 MB26 MB163–164 MB
Kong226–229 MB227–228 MB218–227 MB
Meta48–50 MB18 MB75–76 MB
Studio146–147 MB31–37 MB147–164 MB