Hogyan csökkentsd az alkalmazásod tárhelyköltségét

A tárhelyköltségek csökkentéséhez derítsd ki, mi fut valójában és miért, majd hagyj mindent aludni, amikor senki nem használja. Azokon a tárhelyeken, amelyek nullára skálázzák a szolgáltatást, egy tétlen alkalmazás és egy alvó adatbázis nagyon keveset kerül, így a legnagyobb megtakarítást általában az hozza, ha eltávolítod azt, ami ébren tartja őket – leggyakrabban azt a kódot, amely néhány másodpercenként ellenőrzi az adatbázist –, majd a sávszélesség csökkentésével és a senki által nem használt alkalmazások törlésével.

A legtöbb kis alkalmazásnak nincs forgalmi problémája. Ehelyett „valami mindig be van kapcsolva” a gondja. Ez az útmutató megmutatja, hogyan találod meg és javítod ki, mesterséges intelligencia alkalmazásépítőnek adható promptokkal.

Mire fizetsz valójában?

A kis alkalmazások tárhelyszámlája néhány dologból áll. Ha tudod, melyik a nagy tétel, tudod, hol kell keresni.

Sok modern tárhely, köztük a Mythex, nullára skálázza a szolgáltatást: ha senki nem használja az alkalmazást, a szerver leáll, és nem kerül pénzbe a számítási kapacitás, majd a következő látogatásnál felébred. Ez a kérdést megváltoztatja: a „mekkora a szerverem?” helyett azt kell kérdezni, hogy „miért van ébren a szerverem?”.

1. lépés: Nézd meg, hová megy a pénz

Mielőtt bármit változtatnál, nyisd meg a tárhelyszolgáltatód használati oldalát, és keresd meg:

• Melyik projekt a legdrágább. Gyakran egy alkalmazás teszi ki a számla nagy részét.
• Melyik kategória – számítási kapacitás, adatbázis, sávszélesség vagy tárolás.
• Mikor költ. Egy egyenes vonal éjszaka, amikor nincsenek felhasználóid, arra utal, hogy valami ébren tartja az alkalmazást.

A Mythexen a Usage details oldal az elmúlt 30 napot mutatja, Build (a mesterséges intelligencia ügynök) és Run (tárhely, sávszélesség, adatbázis és fájltárolás) bontásban, projektenkénti részletezéssel.

2. lépés: Hagyd elaludni a tétlen alkalmazásokat és adatbázisokat

Ez a valódi áttétel a legtöbb kis alkalmazásnál. Az az adatbázis, amely tétlenség esetén elalszik, és a következő kérésre felébred, csendes órákban szinte semmibe nem kerül. Az az adatbázis, amelyet néhány másodpercenként lekérdeznek, soha nem lesz tétlen, így egész nap fizetsz érte.

A Mythex hosting limits oldala leírja, hogyan működik ez a közzétett alkalmazásoknál: egy alvó alkalmazás nem költ számítási kapacitásra, az adatbázis a legkisebb méretével indul, foglalt időszakban nő, 5 perc tétlenség után elalszik, és a méretének és az ébren töltött időnek a szorzatáért számláznak. Vagyis egy olyan alkalmazás, amely néhány percenként, éjjel-nappal lekérdezi az adatbázisát, úgy számláz, mintha mindig foglalt volna – míg ugyanaz az alkalmazás háttérzaj nélkül nagyon keveset kerül.

Gyakori dolgok, amelyek ébren tartják az alkalmazást:

• Lekérdezés (polling). Olyan oldal, amely 2–5 másodpercenként megkérdezi a szervertől, hogy „van-e új?”. Ha egy laptopon nyitva hagyod a fület, az adatbázis soha nem alszik el.
• Automatikusan frissülő irányítópultok, amelyek időzítőre töltik újra az adatokat, akkor is, ha senki nem nézi.
• Üzemidő-figyelők, amelyek percenként pingelik az alkalmazást.
• Háttérciklusok a szerverkódban – egy setInterval, amely örökké tisztít vagy szinkronizál adatokat.
• Ütemezett „életben tartó” kérések, amelyeket valaki azért adott hozzá, hogy elkerülje a lassú első látogatást – ezek úgy működnek, hogy megakadályozzák az alvást, pontosan az, ami pénzbe kerül.

Kérd meg a mesterséges intelligenciát, hogy keresse meg őket:

Nézd át a kódot, és keress mindent, ami időzítőn fut vagy ismételten lekérdezi az adatbázist: lekérdezés (polling), setInterval, automatikus frissítés, háttérciklusok. Sorold fel mindegyiket, hogy milyen gyakran fut, és fut-e akkor is, amikor senki nincs rajta az oldalon. Még ne változtass semmin.

Ezután javítsd őket egyenként:

A műszerfal 3 másodpercenként lekérdezi a /api/orders végpontot. Változtasd meg úgy, hogy csak akkor frissüljön, amíg a böngészőfül látható, és 3 másodperc helyett 60 másodpercenként. Adj hozzá egy kézi Frissítés gombot.

Ha az alkalmazásodnak valóban élő frissítésekre van szüksége (chat, élő eredménytábla), kérdezd meg, hogy tud-e küldeni frissítéseket csak akkor, amikor valami változik, ahelyett hogy folyamatosan kérdezne. Sok alkalmazásnál elég, ha „frissít, amikor a felhasználó visszatér a fülre”.

3. lépés: Méretezd jól a szervert

A nagyobb gépek óránként többe kerülnek. Sok AI-val épített alkalmazás egy megfelelő alapméretről indul; a problémák akkor jönnek, amikor „több erőt” kérnek egy lassúságra, amely valójában egy lassú lekérdezés volt.

• Tartsd meg a legkisebb méretet, amely a forgalmadat hiba nélkül kiszolgálja.
• Ha memória-összeomlásokat látsz, először kérdezd meg a mesterséges intelligenciát, hogy az alkalmazás nem tölt-e be túl sokat a memóriába (egy egész táblát egy oldalnyi eredmény helyett).
• Csak akkor adj hozzá gépeket, ha mért forgalom indokolja.

A Mythexen a gép méretét közzétételkor a szükségletek alapján választják ki, a többletgépek pedig csak nagy forgalomnál indulnak, és amikor a forgalom csökken, visszaalszanak. A költség a mérethez igazodik, ezért ha úgy gondolod, hogy túl nagy, kérj a chatben kisebb méretet.

4. lépés: Csökkentsd a sávszélességet

A sávszélesség az, amit a látogatók letöltenek. A képek általában a legnagyobb részt teszik ki.

• Tömörítsd a képeket, és használj modern formátumokat, például WebP-t vagy AVIF-et.
• Méretezd át a képeket a megjelenített méretükre. Egy 4000 pixeles fotó, amely 400 pixeles bélyegképként jelenik meg, a letöltött adat nagy részét pazarolja.
• Töltsd be lusta módon (lazy-load) a hajtás alatti képeket.
• Gyorsítótárazd a statikus fájlokat (szkriptek, stílusok, képek), hogy a visszatérő látogatók ne töltsék le újra őket. Lásd: mi a gyorsítótárazás.
• Ne engedd, hogy az alkalmazás minden oldalmegtekintésnél nagy fájlokat adjon ki.

Nézd át az alkalmazás minden képét. Méretezd át őket a legnagyobb megjelenített méretükre, alakítsd át WebP formátumra, és töltsd be lusta módon mindent, ami az első képernyő alatt van. Mondd meg az összes méretet előtte és utána.

A gyorsabb oldalak és a kisebb sávszélesség általában együtt járnak – lásd: hogyan tedd gyorsabbá a weboldalad.

5. lépés: Takarítsd ki, amit senki nem használ

• Vond vissza a közzétételt a régi alkalmazásoktól – tesztelő telepítések, befejezett kísérletek, tavalyi eseményoldal.
• Töröld a régi feltöltéseket, naplókat és exportokat, amelyekre nincs szükséged.
• Töröld a már nem használt megosztott előnézeti linkeket. A Mythexen egy előnézeti link megnyitása felébreszti a projektet, és a kreditjeidből fut, így egy elfelejtett link, amelyet valaki folyamatosan megnyit, továbbra is költ.
• Távolítsd el a nem használt szolgáltatásokat – egy API-szervert vagy munkafolyamatot, amelyet az alkalmazás már nem hív.

6. lépés: Fontold meg a statikus oldalt

Ha az oldalad nem igényel bejelentkezést, nincsenek mentett felhasználói adatai és nincs szerveroldali logikája – például egy marketingoldal, portfólió vagy étlap –, akkor lehet statikus oldal: sima fájlok, CDN-ről kiszolgálva. Nincs szerver vagy adatbázis, amelyet futtatni kellene. A Mythexen a statikus oldalak nem használnak kreditet, amíg csak ott vannak.

Ennek az oldalnak nincsenek bejelentkezései vagy mentett adatai. Át lehet építeni statikus oldallá szerver nélkül? Mit veszítenénk?

7. lépés: Figyeld a fizetős API-hívásokat

Az olyan alkalmazásoknál, amelyek mesterséges intelligencia-modelleket, térképeket vagy SMS-t hívnak, a harmadik féltől származó számlák a tárhelyköltséget is túlszárnyalhatják.

• Kérj bejelentkezést minden olyan funkcióhoz, amely hívásonként pénzbe kerül.
• Adj felhasználónkénti korlátot (lásd: mi a sebességkorlátozás).
• Gyorsítótárazd a nem változó válaszokat, például ugyanannak a címnek a geokódolását.
• Állíts be költési korlátot vagy riasztást minden szolgáltatónál.

Gyakori hibák

• Becslés mérés helyett. Először nézd meg a használati bontást; a drága rész gyakran nem az, amire számítanál.
• Nagyobb szerver vásárlása a lassúság megoldására. Egy hiányzó adatbázisindex vagy a túl sok adat betöltése általában a valódi ok.
• Mindent lekérdezni. Minden néhány másodperces időzítő oka annak, hogy az adatbázis ébren marad.
• Az alkalmazás pingelése, hogy „meleg” maradjon. Ez eltünteti a nullára skálázás megtakarítását. Fogadd el a rövid felébredést az első látogatásnál, vagy fizess tudatosan az állandó üzemért.
• Régi telepítések elfelejtése. A nem használt alkalmazások adatbázisokkal és háttérfeladatokkal csendben összeadódnak.
• Tömörítetlen képek. Kis oldalaknál gyakran ez a legnagyobb sávszélesség-költség.

Ellenőrzőlista

• Tudom, melyik projekt és melyik kategória (számítási kapacitás, adatbázis, sávszélesség, tárolás) a legdrágább.
• Semmi nem kérdezi le néhány másodpercenként az adatbázist, amikor senki nem figyel.
• A műszerfalak ésszerű időközönként frissülnek, vagy csak akkor, amikor a fül látható.
• Nincs olyan üzemidő-figyelő vagy háttérciklus, amely ok nélkül ébren tartja az alkalmazást.
• A szerver a legkisebb méret, amely működik.
• A képek át vannak méretezve, tömörítve és lusta módon töltődnek be; a statikus fájlok gyorsítótárazva vannak.
• A régi alkalmazások közzétételét visszavontam, a régi fájlokat töröltem, a nem használt előnézeti linkeket eltávolítottam.
• Az adat- vagy bejelentkezés nélküli oldalak statikusak.
• A fizetős API-kon van bejelentkezés, felhasználónkénti korlát és szolgáltatói költési riasztás.

Költségcsökkentés a Mythexen

A Mythex egyetlen kreditegyenleget használ az építéshez és a tárhelyhez, így a tárhelyen megtakarított összeg több kreditet hagy az építésre. Néhány Mythex-specifikus pont:

• A közzétett alkalmazások és adatbázisaik tétlenség esetén elaludnak, és a következő látogatásnál felébrednek. Az adatbázis 5 perc tétlenség után elalszik, ezért a folyamatos lekérdezés megszüntetése általában a legnagyobb nyereség.
• A Pro csomag a tárhely, az adatbázisok, a sávszélesség, a fájltárolás és az előnézeti homokozó után a Free díj felét fizeti; a mesterséges intelligencia ugyanannyiba kerül mindkét csomagnál. Lásd: Credits.
• E-mailt kapsz, mielőtt az alacsony egyenleg miatt szünetelne egy közzétett alkalmazás, és a szüneteltetett alkalmazások megtartják az adatbázisukat és fájljaikat.

A futási költségekről általánosabban lásd: mennyibe kerül egy alkalmazás építése és mi a webhosting.

Kérdések