Dimensionner un VPS SaaS à partir d'un budget de charge

Nommez la charge avant de choisir l'hôte

Dessinez le chemin de la requête : reverse proxy, processus d'API, base de données et services externes. Ajoutez le chemin asynchrone : file d'attente, worker et destination d'export. Consignez quels composants partagent l'hôte, qui contrôle la concurrence et quelles données doivent survivre à une reconstruction. Vous avez besoin de métriques applicatives et d'une charge hors production avec des données représentatives ; ce guide ne suppose pas d'instance PrivacyNodes provisionnée.

Pour une API de reporting illustrative, une requête HTTP lit les paramètres du compte et met un export en file d'attente. Le worker parcourt les lignes et écrit un fichier. Une réponse rapide de mise en file d'attente ne prouve pas que l'export peut se terminer pendant le trafic de pointe. Incluez le nettoyage planifié et le chevauchement de déploiement dans le plan de test.

Incluez le chevauchement dans la feuille de calcul de mémoire

Il s'agit d'entrées de planification hypothétiques en MiB, non de mesures ni de promesses concernant PrivacyNodes. Remplacez-les par les exigences applicatives observées. Le RSS inclut les mappages partagés résidents ; additionner le RSS de chaque processus peut compter la mémoire en double. La mémoire disponible de l'hôte est plus utile que de considérer tout le cache du système de fichiers comme définitivement indisponible.

Référence technique : Comptabilisation de la mémoire des processus Linux.

C'est trop proche d'une enveloppe 4 GB nominale pour supposer une capacité confortable. Vérifiez la mémoire réelle rapportée par l'hôte et si les pics se chevauchent. Réduisez la concurrence, déplacez un composant ou ajoutez de la mémoire ; ne supprimez pas la réserve juste pour faire tenir le tableau.

PostgreSQL work_mem est une allocation par opération, non une limite totale de la base de données. Les sessions et opérations concurrentes peuvent multiplier son effet. Les conteneurs Docker n'ont par défaut aucune contrainte de CPU ni de mémoire ; une image n'est pas une politique de ressources.

Référence technique : Consommation de ressources PostgreSQL · Contraintes de ressources Docker.

Mesurez le CPU parallèlement à l'âge de la file d'attente

Exercez ensemble une requête ordinaire, le rapport utile le plus lent, une dépendance en échec et un export. Consignez les percentiles de latence, les erreurs, le CPU de l'hôte, la concurrence des workers et l'âge de la tâche la plus ancienne sur le même intervalle. Une pression CPU avec croissance de la file d'attente suggère une action différente d'un faible CPU avec une longue attente de base de données.

Commencez l'exemple avec un export en cours. Si le worker attend un stockage externe, du CPU supplémentaire peut peu changer. S'il sature de façon répétée un cœur pendant que la latence de l'API augmente, testez un lot d'export plus petit ou un budget de worker séparé. Modifiez un seul facteur et répétez le même scénario avant d'acheter de la capacité.

Budgétez la prochaine opération de maintenance

Listez les fichiers et index de base de données, les téléversements, les journaux, les exports temporaires, les artefacts de version et l'espace libre pour la maintenance. Consignez la croissance par semaine et le moment où votre réserve serait épuisée. Un jeu de données de 20 GB plus une copie temporaire de 20 GB nécessite plus de 20 GB, même lorsque le trafic applicatif ordinaire est calme.

Attribuez la rotation des journaux et l'expiration des exports. Gardez les copies de récupération en dehors de la limite de défaillance de l'hôte. Un stockage VPS supplémentaire élargit l'allocation de travail ; une copie sur ce même disque n'est pas une sauvegarde indépendante. Testez à la fois le fonctionnement normal et une version s'exécutant parallèlement à une sauvegarde ou à un export.

Rédigez une décision qui pourra être revue

Votre sortie est une feuille de calcul, une description de charge et un déclencheur de revue : âge de la tâche la plus ancienne qui augmente pendant le test représentatif, espace de maintenance qui diminue, ou version qui ne peut pas coexister avec les processus actuels. Consignez des observations au lieu d'inventer un seuil universel de pourcentage CPU.

Comparez App 2 et Scale 4 à ces contraintes. Si le résultat vous surprend encore, suivez une requête lente à travers la pile. Cet exercice estime votre charge ; il n'établit ni référence fournisseur, ni capacité de trafic, ni disponibilité.