Bepaal de grootte van een SaaS-VPS op basis van een werkbelastingsbudget

Benoem het werk voordat u de host kiest

Teken het verzoekpad: reverse proxy, API-proces, database en externe services. Voeg het asynchrone pad toe: wachtrij, worker en exportbestemming. Noteer welke componenten de host delen, wie gelijktijdigheid beheert en welke gegevens een rebuild moeten overleven. U hebt applicatiemetrieken en een niet-productiewerkbelasting met representatieve gegevens nodig; deze handleiding gaat niet uit van een ingerichte PrivacyNodes-instantie.

Voor een illustratieve rapportage-API leest een HTTP-verzoek accountinstellingen en zet een export in de wachtrij. De worker scant rijen en schrijft een bestand. Een snel wachtrijantwoord bewijst niet dat de export tijdens piekverkeer kan worden voltooid. Neem geplande opschoning en deployment-overlap op in het testplan.

Neem overlap op in het geheugenwerkblad

Dit zijn hypothetische planningsinvoerwaarden in MiB, geen metingen of beloften over PrivacyNodes. Vervang ze door waargenomen applicatievereisten. RSS omvat residente gedeelde mappings; het optellen van de RSS van elk proces kan geheugen dubbel tellen. Het beschikbare geheugen van de host is nuttiger dan alle bestandssysteemcache als permanent onbeschikbaar te behandelen.

Technische referentie: Linux procesgeheugenboekhouding.

Dit ligt te dicht bij een nominaal 4 GB-envelope om comfortabele capaciteit aan te nemen. Controleer het werkelijke geheugen dat door de host wordt gerapporteerd en of pieken overlappen. Verminder gelijktijdigheid, verplaats een component of voeg geheugen toe; verwijder de reserve niet alleen om de tabel te laten passen.

PostgreSQL work_mem is een toelage per bewerking, geen totale databaselimiet. Gelijktijdige sessies en bewerkingen kunnen het effect ervan vermenigvuldigen. Docker-containers hebben standaard geen CPU- of geheugenbeperkingen; een image is geen resourcebeleid.

Technische referentie: PostgreSQL resourceverbruik · Docker resourcebeperkingen.

Meet CPU naast wachtrijleeftijd

Oefen een gewoon verzoek, het langzaamste nuttige rapport, een mislukte afhankelijkheid en een export samen. Registreer latentiepercentielen, fouten, host-CPU, workergelijktijdigheid en oudste-taakleeftijd over hetzelfde interval. CPU-druk met wachtrijgroei suggereert een andere actie dan lage CPU met een lange databasewacht.

Start het voorbeeld met één export onderweg. Als de worker op externe opslag wacht, kan extra CPU weinig veranderen. Als hij herhaaldelijk een core verzadigt terwijl de API-latentie stijgt, test dan een kleinere exportbatch of een apart workerbudget. Wijzig één factor en herhaal hetzelfde scenario voordat u capaciteit koopt.

Budgetteer de volgende onderhoudsbewerking

Maak een lijst van databasebestanden en indexen, uploads, logs, tijdelijke exports, release-artifacts en vrije ruimte voor onderhoud. Registreer de groei per week en wanneer uw reserve uitgeput zou raken. Een 20 GB dataset plus een 20 GB tijdelijke kopie vereist meer dan 20 GB, zelfs wanneer gewoon applicatieverkeer rustig is.

Wijs logrotatie en exportverval toe. Bewaar herstelkopieën buiten de faalgrens van de host. Extra VPS-opslag vergroot de werkallocatie; een kopie op diezelfde schijf is geen onafhankelijke back-up. Test zowel normale werking als een release die naast een back-up of export draait.

Schrijf een beslissing die kan worden herzien

Uw output is een werkblad, een werkbelastingsbeschrijving en een reviewtrigger: groeiende oudste-taakleeftijd tijdens de representatieve test, krimpende onderhoudsruimte, of een release die niet naast huidige processen kan bestaan. Registreer observaties in plaats van een universele CPU-percentagedrempel te verzinnen.

Vergelijk App 2 en Scale 4 met die beperkingen. Als het resultaat u nog steeds verrast, volg één langzaam verzoek door de stack. Deze oefening schat uw werkbelasting; het stelt geen leveranciersbenchmark, verkeerscapaciteit of beschikbaarheid vast.