Whilst the Modr8 bot platform is a SaaS package, requiring no code knowledge, we do want to share some optimisation techniques we have found to be crucial to running any service against the Telegram bot API.
An unresponsive or slow bot, no matter its purpose can turn users off from engagement and ultimately reduce your usage. If you are coding your own bot you may find the following tips quite useful.
Optimisation 1: Server location
Without a doubt one of the single most effective solutions for improving the speed your bot processes messages and returns a response to users comes down to the server location where it is hosted. This becomes most apparent when using webhooks as you should receive events in real-time from Telegram without any polling delays.
Telegram offers two protocols for their services:
- The Mobile Protocol aka MTProto: This is served from global locations and your connection is likely to be routed through the closest server providing excellent support for desktop, mobile and browser based applications to receive events in acceptable time.
- The Bot API: This is served from one location, hosted in Amsterdam and is the single point for API requests and responses that the Telegram Bot utilises.
When Modr8 started out we noticed that certain spam messages were being sent to chats and then within a second or two would disappear as our moderation engine removed them. Whilst the overall requirements of filtering such messages were met, the small lag wasn’t satisfactory.
If we run a ping from multiple global locations on the Bot API end-point https://api.telegram.org we return the following results:
Amsterdam is blazing fast with its pong response and as we move outside of Europe we begin to see a slow down.
Whilst 150–200ms pings may be acceptable for some applications, often you can be making multiple API calls with a Telegram Bot, especially one that is moderating a chat so this soon bulks out to be a noticeable lag.
Modr8 began it’s life hosted in San Franciso and as you can see 150ms became a bottleneck when processing hundreds of messages a second. We decided to relocate closer to Amsterdam giving us on avg 12ms response times.
Optimisation 2: Cache Expensive Calls
Telegram has not published any hard rules on its API limits, but we have seen many open source/single token community bots that hit API limits quite easily as they are being used by many groups all compounding the number of messages to be processed and API calls.
Modr8 took a different approach, you bring your own token which alleviates the risk of hitting API limits with a shared bot. However, that being said there are still optimisations that can be made.
Certain calls such as getChatAdministrators, working with Files, getting member counts and restricting users can be expensive to continually call, especially those that require multiple in quick succession to produce the desired outcome. We found early that the behaviour of Telegram communities often means you are able to cache results in memory with an expiry time reducing the number of hits against the API.
A good example of this is caching the chat administrators. Assessing the permissions of a user executing commands and running messages through filters to display admin lists could result in numerous API calls, however we do this once and cache the results within Redis. Each chat has their admins cached with a TTL (time to live) expiry, if the results expired we call the API again and re-seed the cache.
Optimisation 3: Webhooks vs Polling
Whilst its easy to switch to a polling technique for pulling updates from the Bot API it is also a process which by its very nature reduces the responsiveness of your bot to the end user. Between each gap in requesting the getUpdates call your bot has dead time and the user is waiting.
Polling is an ideal setup for development and rapid prototyping, but if you start to receive heavier traffic you will want to switch to Webhooks. Bear in mind, this also reduces your calls per second to the API so you are getting back a few extra calls before reaching API limits.
Webhooks can be used to send and receive messages, for ease you may wish to simply receive webhook events and process the message and use the typical http request back to the API to offer your response. The choice is yours hear but receiving real time updates via webhook can drastically reduce loads and also improve responsiveness.
Optimisation 4: File Handling
If you are serving files to your users you mayg notice that there is a delay during the upload and optimisation process before your bot then displays the file. This is especially apparent when waiting for images sent as weblinks.
Telegram is pretty clever and has a built in CDN, if you are able to upload or serve the files earlier, especially coupled with caching the file links provided back by Telegram as per Optimisation 3 you will find the experience much more snappy for users.
In general though, we have actually found the process of handling files via the Bot API to be pretty clunky and it’s something which we prefer to handle ourselves from an external CDN and simply link users where needed to those files. This has definitely improved overall experience and allows us to take control of expiry times and compression ourselves.
Conclusion
Whilst the suggested optimisations may be obvious to many developers, sometimes the simplest methods bear the greatest rewards. For Modr8, caching and server location has been a game changer and allowed our platform to focus on horizontal scaleability to handle loads rather than dealing with hard stop bottlenecks due to round trip lags.
If you are looking for an all in one Telegram group management platform providing spam prevention, analytics and user management sign up for our free tier licence where all the functionality is available for you to test out!
Top comments (1)
Thank you for the great article! Accidentally, I used Ngrok while developing on my laptop and was pleasantly surprised by the blazing response! Upon further investigation, I discovered that Ngrok connected me to a server in Europe. As I read your insightful article, I realized the impact of server location on response times. In production, my webhook is based in UAE, and now I'm considering recreating it in Amsterdam to see how it affects performance. Your article has been incredibly helpful. Many thanks!