Cum reduci costurile de găzduire pentru aplicația ta

Pentru a reduce costurile de găzduire, află ce rulează efectiv și de ce, apoi lasă totul să doarmă când nu îl folosește nimeni. Pe găzduirile care coboară la zero, o aplicație inactivă și o bază de date adormită costă foarte puțin, așa că cele mai mari economii vin de obicei din eliminarea a ceea ce le ține trezite — cel mai des cod care verifică baza de date la fiecare câteva secunde — și apoi din micșorarea traficului și ștergerea aplicațiilor pe care nu le folosește nimeni.

Majoritatea aplicațiilor mici nu au o problemă de trafic. Au o problemă de tipul „ceva rulează mereu”. Acest ghid arată cum o găsești și o repari, cu prompturi pe care le poți da unui constructor de aplicații cu AI.

Pentru ce plătești de fapt

Facturile de găzduire pentru aplicațiile mici vin dintr-un număr mic de lucruri. Dacă știi care este mare, știi unde să te uiți.

Multe găzduiri moderne, inclusiv Mythex, coboară la zero: când nimeni nu folosește aplicația, serverul se oprește și nu costă nimic pentru calcul, apoi se trezește la următoarea vizită. Asta schimbă întrebarea de la „cât de mare e serverul meu?” la „de ce e serverul meu treaz?”.

Pasul 1: Uită-te unde se duc banii

Înainte să schimbi ceva, deschide pagina de utilizare a găzduirii și află:

• Ce proiect costă cel mai mult. Adesea o singură aplicație reprezintă cea mai mare parte a facturii.
• Ce categorie — calcul, bază de date, lățime de bandă sau stocare.
• Când cheltuie. O linie plată peste noapte, când nu ai utilizatori, este indiciul că ceva ține aplicația trează.

Pe Mythex, detaliile de utilizare arată ultimele 30 de zile împărțite în Build (agentul AI) și Run (găzduire, lățime de bandă, bază de date și stocare de fișiere), cu o defalcare pe proiect.

Pasul 2: Lasă aplicațiile și bazele de date inactive să doarmă

Aceasta este pârghia reală pentru majoritatea aplicațiilor mici. O bază de date care doarme când e inactivă și se trezește la următoarea cerere costă aproape nimic în orele liniștite. O bază de date interogată la fiecare câteva secunde nu ajunge niciodată în inactivitate, deci plătești toată ziua.

Limitele de găzduire ale Mythex, explicate aici, descriu cum funcționează asta pentru aplicațiile publicate: o aplicație care doarme nu consumă nimic pentru calcul, iar baza de date pornește la cea mai mică dimensiune, crește când este ocupată, doarme după 5 minute de inactivitate și se taxează pentru dimensiunea sa înmulțită cu timpul în care a fost trează. Deci o aplicație care interoghează baza de date chiar și o dată la câteva minute, zi și noapte, este taxată ca și cum ar fi mereu ocupată — în timp ce aceeași aplicație fără activitate de fundal costă foarte puțin.

Lucruri frecvente care țin o aplicație trează:

• Interogarea repetată (polling). O pagină care întreabă serverul „e ceva nou?” la fiecare 2–5 secunde. Lasă un tab deschis pe un singur laptop și baza de date nu doarme niciodată.
• Tablouri de bord care se reîmprospătează automat, reîncărcând datele pe un cronometru, chiar când nu le privește nimeni.
• Monitoare de disponibilitate care fac ping aplicației la fiecare minut.
• Bucle de fundal în codul serverului — un setInterval care curăță sau sincronizează date la nesfârșit.
• Cereri programate de „keep-alive” adăugate cuiva ca să evite o primă vizită lentă — ele funcționează prin împiedicarea somnului, ceea ce tocmai costă bani.

Cere AI-ului să le găsească:

Caută în cod orice rulează pe un cronometru sau interoghează repetat baza de date: polling, setInterval, reîmprospătare automată, bucle de fundal. Listează fiecare, cât de des rulează și dacă rulează când nu are nimeni pagina deschisă. Nu schimba nimic încă.

Apoi repară-le pe rând:

Tabloul de bord interoghează /api/orders la fiecare 3 secunde. Schimbă-l ca să se reîmprospăteze doar cât timp tab-ul browserului este vizibil și la fiecare 60 de secunde în loc de 3. Adaugă un buton manual de Refresh.

Dacă aplicația ta chiar are nevoie de actualizări în timp real (un chat, un scor live), întreabă dacă poate trimite actualizările doar când se schimbă ceva, în loc să întrebe constant. Pentru multe aplicații, „reîmprospătează când utilizatorul revine în tab” este suficient.

Pasul 3: Dimensionează corect serverul

Mașinile mai mari costă mai mult pe oră. Multe aplicații construite cu AI pornesc de la o dimensiune implicită care este suficientă; problemele apar când se cere „mai multă putere” pentru a repara o lentoare care de fapt venea dintr-o interogare lentă.

• Păstrează cea mai mică dimensiune care servește traficul tău fără erori.
• Dacă vezi blocaje din cauza memoriei, întreabă mai întâi AI-ul dacă aplicația încarcă prea mult în memorie (un tabel întreg în loc de o pagină de rezultate).
• Adaugă mașini doar dacă ai trafic măsurat care le cere.

Pe Mythex, dimensiunea mașinii se alege la publicare în funcție de ce are nevoie aplicația, iar mașini suplimentare pornesc doar când traficul este mare și se întorc să doarmă când scade. Costul urmează dimensiunea, deci cere în chat una mai mică dacă crezi că e supradimensionată.

Pasul 4: Redu lățimea de bandă

Lățimea de bandă este ceea ce descarcă vizitatorii. Imaginile sunt de obicei cea mai mare parte.

• Comprimă imaginile și servește formate moderne, cum ar fi WebP sau AVIF.
• Redimensionează imaginile la dimensiunea la care sunt afișate. O fotografie de 4.000 de pixeli afișată ca miniatură de 400 de pixeli risipește cea mai mare parte din ce se descarcă.
• Încarcă leneș imaginile de sub prima zonă vizibilă.
• Pune în cache fișierele statice (scripturi, stiluri, imagini) ca vizitatorii care revin să nu le descarce din nou. Vezi ce este cache-ul.
• Nu lăsa aplicația să ofere fișiere mari la fiecare vizualizare de pagină.

Verifică fiecare imagine din aplicație. Redimensionează-o la cea mai mare dimensiune la care este afișată, convertește-o în WebP și încarc-o leneș pe orice este sub primul ecran. Spune-mi dimensiunea totală înainte și după.

Pagini mai rapide și lățime de bandă mai mică merg de obicei împreună — vezi cum faci site-ul tău mai rapid.

Pasul 5: Curăță ce nu folosește nimeni

• Depublică aplicațiile vechi — deploy-uri de test, experimente terminate, site-ul evenimentului de anul trecut.
• Șterge încărcările, jurnalele și exporturile vechi pe care nu le mai ai nevoie.
• Șterge linkurile de previzualizare partajate pe care nu le mai folosești. Pe Mythex, deschiderea unui link de previzualizare trezește proiectul și rulează pe creditele tale, deci un link uitat pe care cineva îl tot deschide continuă să coste.
• Elimină serviciile nefolosite — un server API sau un worker pe care aplicația nu îl mai apelează.

Pasul 6: Ia în considerare un site static

Dacă site-ul tău nu are autentificare, nu are date salvate ale utilizatorilor și nu are logică de server — un site de marketing, un portofoliu, un meniu — poate fi un site static: fișiere simple servite dintr-un CDN. Nu există server sau bază de date care să ruleze. Pe Mythex, site-urile statice nu consumă credite cât timp stau pe loc.

Acest site nu are autentificări sau date salvate. Poate fi reconstruit ca site static fără server? Ce am pierde?

Pasul 7: Urmărește apelurile API plătite

Pentru aplicațiile care apelează modele AI, hărți sau SMS, facturile terților pot depăși cu mult găzduirea.

• Cere autentificare pentru tot ce costă bani per apel.
• Adaugă o limită per utilizator (vezi ce este limitarea ratei).
• Pune în cache răspunsurile care nu se schimbă, cum ar fi geocodarea aceleiași adrese.
• Setează plafoane de cheltuieli sau alerte la fiecare furnizor.

Greșeli frecvente

• Să ghicești în loc să măsori. Verifică mai întâi defalcarea utilizării; partea scumpă este adesea altceva decât te-ai aștepta.
• Să cumperi un server mai mare ca să repari lentoarea. Un index lipsă în baza de date sau încărcarea prea multor date este de obicei cauza reală.
• Să interoghezi totul. Fiecare cronometru la câteva secunde este un motiv ca baza de date să rămână trează.
• Să faci ping aplicației ca să o „încălzești”. Asta elimină economia pe care o dă coborârea la zero. Acceptă o scurtă trezire la prima vizită sau plătește conștient pentru funcționare permanentă.
• Să uiți deploy-urile vechi. Aplicațiile nefolosite cu baze de date și joburi de fundal se adună pe nesimțite.
• Imagini necomprimate. Adesea cel mai mare cost de lățime de bandă pentru site-urile mici.

Listă de verificare

• Știu ce proiect și ce categorie (calcul, bază de date, lățime de bandă, stocare) costă cel mai mult.
• Nimic nu interoghează baza de date la fiecare câteva secunde când nu se uită nimeni.
• Tablourile de bord se reîmprospătează la un interval rezonabil sau doar cât timp tab-ul este vizibil.
• Niciun monitor de disponibilitate sau buclă de fundal nu ține aplicația trează fără un motiv.
• Serverul este cea mai mică dimensiune care funcționează.
• Imaginile sunt redimensionate, comprimate și încărcate leneș; fișierele statice sunt în cache.
• Aplicațiile vechi sunt depublicate, fișierele vechi șterse, linkurile de previzualizare nefolosite eliminate.
• Site-urile fără date sau autentificări sunt statice.
• API-urile plătite au autentificare, limite per utilizator și alerte de cheltuieli la furnizor.

Reducerea costurilor pe Mythex

Mythex folosește un singur sold de credite atât pentru construire, cât și pentru găzduire, așa că economiile de găzduire lasă mai multe credite pentru construire. Câteva puncte specifice Mythex:

• Aplicațiile publicate și bazele lor de date dorm când sunt inactive și se trezesc la următoarea vizită. Baza de date doarme după 5 minute de inactivitate, deci eliminarea interogărilor constante este de obicei cel mai mare câștig.
• Planul Pro plătește jumătate din tariful Free pentru găzduire, baze de date, lățime de bandă, stocare de fișiere și sandbox-ul de previzualizare; AI-ul costă la fel pe ambele planuri. Vezi Credite.
• Primești un e-mail înainte ca un sold scăzut să oprească o aplicație publicată, iar aplicațiile oprite își păstrează baza de date și fișierele.

Pentru imaginea de ansamblu asupra costurilor de funcționare, vezi cât costă să construiești o aplicație și ce este găzduirea web.

Întrebări