VPS Telegram-bothoz

Sokkal kevesebbet, mint amennyit általában eladnak. A bot hosszan futó folyamat, amely ideje szinte egészében vár: egy állapotmentes parancsbot kb. 60 MB-ot használ, egy ORM-et, ütemezőt és gyorsítótárat használó pedig inkább 150 MB-ot. Miután az operációs rendszer elveszi a nagyjából 300 MB-ját, egy 1 GB-os gépen még 4 nehéz vagy 12 könnyű botnak marad hely. A FELHASZNÁLÓK száma alig számít, mert a Telegram egyenként juttatja el a frissítéseket a folyamathoz, nem felhasználónként egy kapcsolattal. Ami megváltoztatja a választ, az az Ön által memóriában tartott állapot: egy nagy gyorsítótár, egy folyamaton belüli adatbázis, egy modell.

Kezdésnek long polling, webhook, amikor számít. Long pollingnál a bot kimenő kapcsolatot nyit a Telegram felé, és vár: nincs szüksége domainre, tanúsítványra vagy nyitott portra, így NAT mögött is működik, és ez a leggyorsabb módja annak, hogy valami elinduljon. Webhooknál a Telegram csatlakozik ÖNHÖZ, így nyilvános cím, érvényes TLS-tanúsítvány és az internet felé nyitott port kell, cserébe teljesen megszűnik a lekérdezési ciklus, és jobban skálázódik, ha a bot valóban terhelt. Mindkettő jól fut az itteni legkisebb gépen is. A váltás őszinte oka a terhelés vagy a késleltetés, nem a divat.

A Telegram saját korlátai, nem a miénk: a nyilvános Bot API-t használó bot legfeljebb 20 MB-os fájlokat tölthet le és 50 MB-osat tölthet fel. Saját Bot API szerver futtatásával ez 2 GB-ra nő, és ami fontosabb, a fájlok a szervere lemezére kerülnek, nem a Telegramén haladnak át. Ez az egyetlen változás, amely valóban befolyásolja, milyen gépre van szüksége: hirtelen számít a lemez és az adatforgalom, ezért a fenti táblázat ehhez a sorhoz rendeli a(z) BD-8 csomagot, a többihez nem.

Szöveges bot soha. Médiabot talán, és megér harminc másodpercnyi számolást: átlagos fájlméret × napi üzenetek × 30. Napi ötvenezer 3 MB-os hangüzenet havonta kb. 4.3 TB, ami a legtöbb olcsó csomag keretét meghaladja, de messze elmarad a(z) BD-8 32 TB-jától, vagy az Unmetered termékvonaltól, ahol a kérdés fel sem merül. Mindkét irány számít: a bot által fogadott és küldött fájl egyaránt forgalom.

Systemd unit, nem screen munkamenet. Írjon egy kis service fájlt Restart=always beállítással, engedélyezze, és a bot összeomlás és újraindítás után is visszaáll, anélkül hogy ébren kellene lennie. Ez a leggyakoribb oka annak, hogy egy bot „leáll” egy VPS-en, és ez nem tárhelyprobléma: a kézzel indított folyamat azzal az SSH-munkamenettel együtt hal meg, amely elindította. Az újraindítási szabállyal futó Docker ugyanezt elvégzi, ha inkább így csomagolná.

Igen, és a legtöbbeknek érdemes. Mindegyik külön folyamat saját systemd unittal és saját tokennel; a gépen és igény szerint az adatbázison osztoznak, máson nem. A táblázatban szereplő számítás pontosan erre a kérdésre felel: egy 4 GB-os gép 25 nehéz botot bír el, mielőtt a memória szűk keresztmetszetté válik. Ha különböző embereknek szólnak, tartsa őket külön portokon és külön felhasználók alatt.

Bárhol, ahol a felhasználói elérik, és a Telegramhoz mért késleltetése elfogadható: a bot a Telegram infrastruktúrájával kommunikál, nem közvetlenül a felhasználóival, így a szokásos „legyen közel a közönséghez” szabály itt kevésbé fontos, mint egy weboldalnál. Ha a bot webes irányítópultot vagy API-t is kiszolgál ugyanezeknek a felhasználóknak, ahhoz igazítsa a régiót. Ha bizonytalan, helyezzen üzembe óránkénti díjazással két régióban, mérjen, és törölje azt, amelyik rosszabbul teljesít: óránként $0.0113 mellett ez olcsó kísérlet.