Рубрика #мюсли
Это пост-жалоба на
@BotSupport и в целом на то, как развивается платформа ботов в Телеграме. Пост можете форвардить напрямую руководству мессенджера или тем, кто занимается платформой ботов. Я не знаю, как дела обстоят у других ботов, но
@voicybot болеет сильно в часы пик по причинам, которые я подозреваю — но не могу никак подтвердить из-за бездействия поддержки.
На данный момент, через
@voicybot проходит в районе 2 300 000 апдейтов в сутки — это примерно 27 апдейтов в секунду. Немного, если брать среднее число — но если учесть, что 80% апдейтов приходит в окно в 20% времени — появляется очень большая проблема, в которой бутылочным горлышком становится механизм доставки апдейтов серверами Телеграма.
Есть два механизма на данный момент: поллинг и вебхуки. Поллинг отпал сразу, так как он позволяет получать 100 апдейтов
за раз последовательно. То есть при задержке в 500 миллисекунд бот начнет запаздывать с ответами уже при 200 апдейтах в секунду. Вебхуки — это уже другое дело: сервера Телеграма могут
параллельно посылать запросы на сервер
@voicybot для
каждого апдейта отдельно. И все было бы хорошо, если бы не ограничение в 100 параллельных исходящих подключений от серверов Телеграма.
Предположим, сервер
@voicybot отвечает за те же 500 миллисекунд. Это снова говорит о том, что при 200 апдейтах в секунду бот начнет затормаживать, так как более 100 апдейтов за каждые 500 миллисекунд сервера Телеграма отправить не могут.
Что же происходит в реальной жизни? Я сегодня утром перезагрузил
@voicybot, он лежал примерно 30 секунд — и набралось около 5000 непринятых апдейтов (см. приложенный скриншот). Это примерно 166 апдейтов в секунду — уже в момент окончания часов пика! А в сам час пик апдейты настолько сильно задерживались из-за этого ограничения, что время ответа у бота превысило 5 минут. 5 минут, Карл!
При том, сервера
@voicybot отвечают буквально мгновенно (см. приложенный скриншот — не обращайте внимание на
processed логи, они не влияют на время ответа серверам Телеграму) — по 10-20 миллисекунд на апдейт. Думаю, из-за того, что сервера общаются по Интернету, можно докинуть 450-500 миллисекунд на ответ. Но факт остается фактом:
@voicybot отвечает на вебхуки почти мгновенно, а потом уже разбирается, что же за апдейт пришел на сервер. То есть, теоретически, производительность моего сервера не должна влиять на заторы в апдейтах, приходящих с серверов Телеграма. Да и, более того, мой сервер нагружается
всего на 10% — и это уже после подключения кластеризации на Node.js, что включает в работу все ядра процессора.
В итоге мы видим, что Телеграм чисто физически не может отправить более 200 апдейтов в секунду на сервер
@voicybot — из-за чего создается очередь из апдейтов на стороне серверов Телеграма, которые ждут своей очереди быть посланными на сервер
@voicybot.
Что с этим делать? Есть два максимально простых решения, которые будут одинаково эффективны:
1. Увеличить максимальное количество параллельных вебхуков с 100 до 1000 (а лучше 10 000)
2. Начать отправлять апдейты пачками, а не по одному (batching)
Оба варианта я уже описал товарищам в
@BotSupport — но на первый вариант они ответили, мол, количество параллельных коннектов не должно влиять; а на второй еще не ответили. Более того: я несколько раз просил, чтобы они посмотрели на то, как быстро с серверов
@voicybot приходит ответ на вебхуки Телеграма — чтобы точно убедиться, а то вдруг проблема, все-таки, у меня, а не у Телеграма (хоть я уже и минимизировал задержку на моей стороне). И на эту простую просьбу мне тоже никто не ответил.
