Jak obniżyć koszty hostingu aplikacji

Aby obniżyć koszty hostingu, sprawdź, co faktycznie działa i dlaczego, a potem pozwól wszystkiemu zasypiać, gdy nikt z tego nie korzysta. U hostów, które skalują do zera, bezczynna aplikacja i uśpiona baza kosztują bardzo mało, więc największe oszczędności zwykle biorą się z usunięcia tego, co je utrzymuje w czuwaniu — najczęściej kodu, który odpytuje bazę danych co kilka sekund — a potem z ograniczenia transferu i usunięcia aplikacji, których nikt nie używa.

Większość małych aplikacji nie ma problemu z ruchem. Ma problem „coś jest zawsze włączone”. Ten przewodnik pokazuje, jak to znaleźć i naprawić, z gotowymi promptami dla asystenta AI do budowania aplikacji.

Za co faktycznie płacisz

Rachunki za hosting małych aplikacji składają się z kilku pozycji. Wiedza, która jest największa, pokazuje, gdzie szukać.

Wiele nowoczesnych hostów, w tym Mythex, skaluje do zera: gdy nikt nie używa aplikacji, serwer się zatrzymuje i nie kosztuje nic za obliczenia, a budzi się przy następnej wizycie. Zmienia to pytanie z „jak duży jest mój serwer?” na „dlaczego mój serwer jest włączony?”.

Krok 1: Sprawdź, gdzie idą pieniądze

Zanim cokolwiek zmienisz, otwórz stronę zużycia u swojego hosta i znajdź:

• Który projekt kosztuje najwięcej. Często jedna aplikacja to większość rachunku.
• Która kategoria — obliczenia, baza danych, transfer czy przechowywanie.
• Kiedy wydaje. Płaska linia w nocy, gdy nie masz użytkowników, to wskazówka, że coś utrzymuje aplikację przy życiu.

W Mythex Szczegóły zużycia pokazują ostatnie 30 dni podzielone na Build (agent AI) i Run (hosting, transfer, baza danych i przechowywanie plików), z podziałem na projekty.

Krok 2: Pozwól aplikacjom i bazom zasypiać

To główna dźwignia dla większości małych aplikacji. Baza, która zasypia, gdy jest bezczynna, i budzi się przy następnym żądaniu, kosztuje prawie nic w ciche godziny. Baza odpytywana co kilka sekund nigdy nie jest bezczynna, więc płacisz za nią cały dzień.

W limitach hostingu Mythex wyjaśniono, jak to działa dla opublikowanych aplikacji: uśpiona aplikacja nie zużywa nic na obliczenia, a baza startuje w najmniejszym rozmiarze, rośnie podczas pracy, zasypia po 5 minutach bezczynności i jest rozliczana za swój rozmiar pomnożony przez czas, w którym była aktywna. Aplikacja, która odpytuje bazę nawet raz na kilka minut, dzień i noc, jest więc rozliczana jak zawsze zajęta — podczas gdy ta sama aplikacja bez takiej stałej aktywności kosztuje bardzo mało.

Najczęstsze rzeczy, które utrzymują aplikację w czuwaniu:

• Odpytywanie. Strona pyta serwer „czy coś nowego?” co 2–5 sekund. Zostaw taką kartę otwartą na jednym laptopie, a baza nigdy nie zaśnie.
• Automatycznie odświeżające się pulpity, które przeładowują dane na timerze, nawet gdy nikt nie patrzy.
• Monitory dostępności pingujące aplikację co minutę.
• Pętle w tle w kodzie serwera — setInterval, który bez końca czyści lub synchronizuje dane.
• Zaplanowane żądania „keep-alive”, które ktoś dodał, żeby uniknąć wolnego pierwszego wejścia — działają, zapobiegając uśpieniu, czyli dokładnie to, co kosztuje.

Poproś AI, żeby je znalazło:

Przejrzyj kod pod kątem wszystkiego, co działa na timerze albo wielokrotnie odpytuje bazę danych: polling, setInterval, automatyczne odświeżanie, pętle w tle. Wypisz każdą pozycję, jak często się uruchamia i czy działa wtedy, gdy nikt nie ma otwartej strony. Na razie niczego nie zmieniaj.

Potem napraw je po kolei:

Pulpit odpytuje /api/orders co 3 sekundy. Zmień to tak, żeby odświeżał dane tylko wtedy, gdy karta przeglądarki jest widoczna, i co 60 sekund zamiast co 3. Dodaj ręczny przycisk Odśwież.

Jeśli Twoja aplikacja naprawdę potrzebuje aktualizacji na żywo (czat, wynik na żywo), zapytaj, czy może wysyłać aktualizacje tylko wtedy, gdy coś się zmieni, zamiast ciągle pytać. Dla wielu aplikacji wystarczy „odśwież, gdy użytkownik wraca do karty”.

Krok 3: Dobierz odpowiedni rozmiar serwera

Większe maszyny kosztują więcej za godzinę. Wiele aplikacji budowanych przez AI startuje na domyślnym rozmiarze, który wystarcza; problemy biorą się z proszenia o „więcej mocy”, by naprawić wolność, która wynikała z powolnego zapytania.

• Zostaw najmniejszy rozmiar, który obsługuje Twój ruch bez błędów.
• Jeśli widzisz awarie przez pamięć, najpierw zapytaj AI, czy aplikacja nie ładuje do pamięci zbyt dużo (całą tabelę zamiast jednej strony wyników).
• Dodawaj maszyny tylko wtedy, gdy masz zmierzony ruch, który tego wymaga.

W Mythex rozmiar maszyny wybierany jest przy publikacji na podstawie potrzeb aplikacji, a dodatkowe maszyny startują tylko przy dużym ruchu i wracają do uśpienia, gdy spada. Koszt zależy od rozmiaru, więc jeśli uważasz, że jest za duży, poproś o mniejszy w czacie.

Krok 4: Ogranicz transfer

Transfer to to, co pobierają odwiedzający. Obrazy zwykle stanowią jego największą część.

• Kompresuj obrazy i serwuj nowoczesne formaty, takie jak WebP lub AVIF.
• Zmniejszaj obrazy do rozmiaru, w którym są wyświetlane. Zdjęcie 4000 pikseli pokazane jako miniatura 400 pikseli marnuje większość pobranych danych.
• Ładuj obrazy leniwie (lazy-load) poniżej pierwszego ekranu.
• Cache'uj pliki statyczne (skrypty, style, obrazy), żeby powracający odwiedzający nie pobierali ich ponownie. Zobacz czym jest cache.
• Nie pozwalaj aplikacji wysyłać dużych plików przy każdym wyświetleniu strony.

Sprawdź każdy obraz w aplikacji. Zmień ich rozmiar do największego, w jakim są wyświetlane, zamień na WebP i włącz lazy-load dla wszystkiego poniżej pierwszego ekranu. Podaj łączny rozmiar przed i po.

Szybsze strony i mniejszy transfer zwykle idą w parze — zobacz jak przyspieszyć stronę internetową.

Krok 5: Posprzątaj to, czego nikt nie używa

• Zdejmij z publikacji stare aplikacje — wdrożenia testowe, zakończone eksperymenty, zeszłoroczną stronę wydarzenia.
• Usuń stare uploady, logi i eksporty, których nie potrzebujesz.
• Usuń udostępnione linki do podglądu, których już nie używasz. W Mythex otwarcie linku podglądu budzi projekt i działa na Twoich kredytach, więc zapomniany link, który ktoś ciągle otwiera, nadal generuje koszty.
• Usuń nieużywane usługi — serwer API albo worker, którego aplikacja już nie wywołuje.

Krok 6: Rozważ stronę statyczną

Jeśli Twoja strona nie ma logowania, zapisanych danych użytkowników ani logiki serwerowej — strona marketingowa, portfolio, menu — może być stroną statyczną: zwykłymi plikami serwowanymi z CDN. Nie ma serwera ani bazy danych do utrzymania. W Mythex strony statyczne nie zużywają kredytów, kiedy po prostu leżą.

Ta strona nie ma logowania ani zapisanych danych. Czy może zostać przebudowana jako strona statyczna bez serwera? Co byśmy stracili?

Krok 7: Pilnuj płatnych wywołań API

W aplikacjach, które wywołują modele AI, mapy lub SMS, rachunki od zewnętrznych dostawców mogą przewyższyć koszt hostingu.

• Wymagaj logowania do wszystkiego, co kosztuje pieniądze za wywołanie.
• Dodaj limit na użytkownika (zobacz czym jest rate limiting).
• Cache'uj odpowiedzi, które się nie zmieniają, na przykład geokodowanie tego samego adresu.
• Ustaw limity wydatków albo alerty u każdego dostawcy.

Częste błędy

• Zgadywanie zamiast mierzenia. Najpierw sprawdź podział zużycia; drogi element często nie jest tym, czego się spodziewasz.
• Kupowanie większego serwera, by naprawić wolność. Brakujący indeks w bazie albo ładowanie zbyt dużej ilości danych to zwykle prawdziwa przyczyna.
• Odpytywanie wszystkiego. Każdy timer co kilka sekund to powód, by baza nie zasypiała.
• Pingowanie aplikacji, by utrzymać ją „ciepłą”. To znosi oszczędność, jaką daje skalowanie do zera. Zaakceptuj krótkie wybudzenie przy pierwszej wizycie albo płać świadomie za stały czas pracy.
• Zapominanie o starych wdrożeniach. Nieużywane aplikacje z bazami danych i zadaniami w tle po cichu się sumują.
• Nieskompresowane obrazy. Często największy pojedynczy koszt transferu na małych stronach.

Lista kontrolna

• Wiem, który projekt i która kategoria (obliczenia, baza danych, transfer, przechowywanie) kosztuje najwięcej.
• Nic nie odpytuje bazy danych co kilka sekund, gdy nikt nie patrzy.
• Pulpity odświeżają się w rozsądnym interwale albo tylko wtedy, gdy karta jest widoczna.
• Żaden monitor dostępności ani pętla w tle nie utrzymuje aplikacji przy życiu bez powodu.
• Serwer ma najmniejszy rozmiar, który działa.
• Obrazy są przeskalowane, skompresowane i ładowane leniwie; pliki statyczne są cache'owane.
• Stare aplikacje są zdjęte z publikacji, stare pliki usunięte, nieużywane linki podglądu wykasowane.
• Strony bez danych i logowania są statyczne.
• Płatne API mają logowanie, limity na użytkownika i alerty wydatków u dostawców.

Ograniczanie kosztów w Mythex

Mythex używa jednego salda kredytów do budowania i hostingu, więc oszczędności na hostingu zostawiają więcej kredytów na budowanie. Kilka punktów specyficznych dla Mythex:

• Opublikowane aplikacje i ich bazy danych zasypiają, gdy są bezczynne, i budzą się przy następnej wizycie. Baza zasypia po 5 minutach bezczynności, więc usunięcie stałego odpytywania to zwykle największa wygrana.
• Plan Pro płaci połowę stawki Free za hosting, bazy danych, transfer, przechowywanie plików i sandbox podglądu; AI kosztuje tyle samo w obu planach. Zobacz Kredyty.
• Dostajesz e-mail, zanim niski saldo mogłoby wstrzymać opublikowaną aplikację, a wstrzymane aplikacje zachowują swoją bazę danych i pliki.

Szerszy obraz kosztów prowadzenia aplikacji znajdziesz w ile kosztuje zbudowanie aplikacji i czym jest hosting stron internetowych.

Pytania