Een VPS voor een Telegram-bot

Veel minder dan meestal wordt verkocht. Een bot is een langlopend proces dat bijna al zijn tijd wacht: een stateless commandobot zit rond 60 MB, en een bot met een ORM, een scheduler en een cache dichter bij 150 MB. Nadat het besturingssysteem ongeveer 300 MB heeft genomen, heeft een machine van 1 GB nog ruimte voor 4 zware bots of 12 lichte. Het aantal GEBRUIKERS speelt nauwelijks mee, omdat Telegram updates één voor één aan uw proces levert, niet via een verbinding per gebruiker. Wat het antwoord wel verandert, is status die u zelf in het geheugen houdt: een grote cache, een database in het proces, een model.

Begin met long polling, kies webhooks wanneer het ertoe doet. Bij long polling opent uw bot een uitgaande verbinding naar Telegram en wacht: er is geen domein, geen certificaat en geen open poort nodig, dus het werkt achter NAT en is de snelste manier om iets aan de praat te krijgen. Bij een webhook maakt Telegram verbinding met U, dus u hebt een openbaar adres, een geldig TLS-certificaat en een poort open naar internet nodig. In ruil daarvoor verdwijnt de polling-lus volledig en schaalt het beter als de bot echt druk is. Beide draaien prima op de kleinste machine hier. De eerlijke reden om over te stappen is belasting of latentie, geen mode.

De limieten van Telegram, niet de onze: een bot die de openbare Bot API gebruikt kan bestanden tot 20 MB downloaden en tot 50 MB uploaden. Met uw eigen Bot API-server wordt dat 2 GB en, belangrijker, komen de bestanden op de schijf van uw server terecht in plaats van via die van Telegram te lopen. Dat is de enige wijziging die echt verandert welke machine u nodig hebt: ineens doen schijf en dataverkeer ertoe, en daarom zet de tabel hierboven BD-8 bij die rij en niet bij de andere.

Een tekstbot nooit. Een mediabot misschien, en dan is het dertig seconden rekenwerk waard: gemiddelde bestandsgrootte × berichten per dag × 30. Vijftigduizend spraakberichten per dag van 3 MB is ongeveer 4.3 TB per maand. Dat is meer dan de bundel van de meeste goedkope pakketten en lang niet de 32 TB van BD-8, of de lijn zonder verkeersmeting, waar de vraag niet speelt. Beide richtingen tellen: een bestand dat uw bot ontvangt en een bestand dat hij verstuurt zijn allebei verkeer.

Een systemd-unit, geen screen-sessie. Schrijf een klein servicebestand met Restart=always, schakel het in, en de bot komt terug na een crash en na een herstart zonder dat u er wakker voor hoeft te zijn. Dit is de meest voorkomende reden dat een bot op een VPS "uitvalt", en het is geen hostingprobleem: een handmatig gestart proces sterft samen met de SSH-sessie die het startte. Docker met een restart policy doet hetzelfde als u het liever zo verpakt.

Ja, en de meeste mensen zouden dat moeten doen. Elke bot is een apart proces met een eigen systemd-unit en een eigen token; ze delen de machine, desgewenst de database, en verder niets. De rekensom in de tabel gaat precies over deze vraag: een machine met 4 GB biedt plaats aan 25 zware bots voordat geheugen de beperking wordt. Houd ze op aparte poorten en onder aparte gebruikers als ze voor verschillende mensen zijn.

Overal waar uw gebruikers bij kunnen en uw latentie naar Telegram redelijk is. De bot praat met de infrastructuur van Telegram, niet rechtstreeks met uw gebruikers, dus de gebruikelijke regel "dicht bij uw publiek" telt hier minder dan voor een website. Biedt de bot dezelfde gebruikers ook een webdashboard of een API, kies de regio dan daarop. Twijfelt u, implementeer dan per uur in twee regio's, meet, en verwijder de verliezer: $0.0113 per uur maakt dat een goedkoop experiment.