Dobierz VPS SaaS na podstawie budżetu obciążenia

Nazwij pracę przed wyborem hosta

Narysuj ścieżkę żądania: reverse proxy, proces API, baza danych i usługi zewnętrzne. Dodaj ścieżkę asynchroniczną: kolejkę, workera i miejsce docelowe eksportu. Zapisz, które komponenty współdzielą host, kto kontroluje współbieżność i które dane muszą przetrwać przebudowę. Potrzebujesz metryk aplikacji i obciążenia nieprodukcyjnego z reprezentatywnymi danymi; ten przewodnik nie zakłada udostępnionej instancji PrivacyNodes.

Dla ilustracyjnego API raportowania żądanie HTTP odczytuje ustawienia konta i kolejkuje eksport. Worker skanuje wiersze i zapisuje plik. Szybka odpowiedź zakolejkowania nie dowodzi, że eksport może zakończyć się w szczycie ruchu. Uwzględnij w planie testów zaplanowane czyszczenie i nakładanie się wdrożeń.

Uwzględnij nakładanie się w arkuszu pamięci

To hipotetyczne dane planistyczne w MiB, a nie pomiary ani obietnice dotyczące PrivacyNodes. Zastąp je zaobserwowanymi wymaganiami aplikacji. RSS obejmuje rezydentne mapowania współdzielone; sumowanie RSS każdego procesu może podwójnie liczyć pamięć. Dostępna pamięć hosta jest bardziej użyteczna niż traktowanie całego cache systemu plików jako trwale niedostępnego.

Dokumentacja techniczna: Rozliczanie pamięci procesu Linux.

Jest to zbyt blisko nominalnej koperty 4 GB, aby zakładać komfortową pojemność. Sprawdź rzeczywistą pamięć raportowaną przez hosta i czy szczyty nakładają się. Zmniejsz współbieżność, przenieś komponent lub dodaj pamięć; nie usuwaj rezerwy tylko po to, aby tabela się zgadzała.

PostgreSQL work_mem to limit na operację, a nie całkowity limit bazy danych. Współbieżne sesje i operacje mogą zwielokrotnić jego efekt. Kontenery Docker domyślnie nie mają ograniczeń CPU ani pamięci; obraz nie jest polityką zasobów.

Dokumentacja techniczna: Zużycie zasobów PostgreSQL · Ograniczenia zasobów Docker.

Mierz CPU razem z wiekiem kolejki

Przetestuj razem zwykłe żądanie, najwolniejszy użyteczny raport, nieudaną zależność i eksport. Zapisuj percentyle opóźnień, błędy, CPU hosta, współbieżność workera i wiek najstarszego zadania w tym samym przedziale. Presja CPU ze wzrostem kolejki sugeruje inne działanie niż niskie CPU z długim oczekiwaniem na bazę danych.

Rozpocznij przykład z jednym eksportem w toku. Jeśli worker czeka na zewnętrzną pamięć masową, dodatkowy CPU może niewiele zmienić. Jeśli wielokrotnie nasyca rdzeń, a opóźnienie API rośnie, przetestuj mniejszą partię eksportu lub oddzielny budżet workera. Zmień jeden czynnik i powtórz ten sam scenariusz przed zakupem pojemności.

Zaplanuj budżet na następną operację konserwacyjną

Wymień pliki i indeksy bazy danych, przesłane pliki, logi, eksporty tymczasowe, artefakty wydań i wolne miejsce na konserwację. Zapisz wzrost na tydzień i moment wyczerpania rezerwy. Zbiór danych 20 GB plus tymczasowa kopia 20 GB wymaga więcej niż 20 GB, nawet gdy zwykły ruch aplikacji jest niewielki.

Przydziel rotację logów i wygaśnięcie eksportów. Trzymaj kopie odzyskiwania poza granicą awarii hosta. Dodatkowa pamięć VPS zwiększa przydział roboczy; kopia na tym samym dysku nie jest niezależną kopią zapasową. Przetestuj zarówno normalne działanie, jak i wydanie uruchomione równolegle z kopią zapasową lub eksportem.

Zapisz decyzję, do której można wrócić

Twój wynik to arkusz, opis obciążenia i wyzwalacz przeglądu: rosnący wiek najstarszego zadania podczas reprezentatywnego testu, malejące miejsce na konserwację lub wydanie, które nie może współistnieć z bieżącymi procesami. Zapisuj obserwacje zamiast wymyślać uniwersalny próg procentowy CPU.

Porównaj App 2 oraz Scale 4 z tymi ograniczeniami. Jeśli wynik nadal Cię zaskakuje, prześledź jedno wolne żądanie przez stos. To ćwiczenie szacuje Twoje obciążenie; nie ustanawia benchmarku dostawcy, pojemności ruchu ani dostępności.