какая-то хрень у них с сайтом стряслась :)

гугл предлагает идти на https версию, а там сетр от гитхаба

а http выглядит как говно

вроде у них был покрасивше год назад сайтец

Если ты видишь бутстраповский сайт - то все ок :)

обрабатывай их в горутинах

там апдейты складываются в канал, т.е. независимо как ты тупишь с их обработкой - они все равно продолжают приниматься без проблем, правда размер буфера не помню.

ну и отправка через встроеный клиент в 2 потока

если нагрузка большая, то надо своего клиента передавать bot, err := tgbotapi.NewBotAPIWithClient(botToken, client)

там апдейты складываются в канал, т.е. независимо как ты тупишь с их обработкой - они все равно продолжают приниматься без проблем, правда размер буфера не помню.

то есть лучше создать ещё канал, и в нём уже через select перебирать значения? И обрабатывать их горутинами?

то есть лучше создать ещё канал, и в нём уже через select перебирать значения? И обрабатывать их горутинами?

Нет, проще свичом распилить приём типов обновлений и уже в кейсах слать данные в горутины.

ну у меня они еще разделены на "только чтение" и "запись" обновления

и те что чтения сразу улетают в горутины, запись - по ситуации

и соответственно окончание обработки не bot.Send а тоже в канал, который разгребается уже нормальным клиентом

там еще где-то крутилка есть что увеличивает число коннектов со стороны телеги

100 максимум

А зачем?

// WebhookConfig contains information about a SetWebhook request. type WebhookConfig struct { URL *url.URL Certificate interface{} MaxConnections int }

о

Я не совсем понимаю для чего так изгаляться. Получаешь апдейт и на его основе делаешь вообще всё остальное

вон те махконнекшнс

там много нюансов

А уж какой апдейт, ручная стучалка каждую секунду или вебхуки - не суть важно. Канал апдейтов будет один

Нет, проще свичом распилить приём типов обновлений и уже в кейсах слать данные в горутины.

так, наверное, действительно удобнее. Спасибо

Нет, проще свичом распилить приём типов обновлений и уже в кейсах слать данные в горутины.

// Updater for upd := range updates { switch { case upd.Message != nil: go GetMessage(upd.Message) case upd.InlineQuery != nil && len(upd.InlineQuery.Query) <= 255: // Just don't update results if query exceeds the maximum length go GetInlineResults(upd.InlineQuery) case upd.ChosenInlineResult != nil: go TrackChosenInlineResult(upd.ChosenInlineResult) case upd.CallbackQuery != nil: go CheckCallbackQuery(upd.CallbackQuery) } }

И уже в них прыгать и творить что душе угодно

Я не совсем понимаю для чего так изгаляться. Получаешь апдейт и на его основе делаешь вообще всё остальное

так и есть, просто апдейт апдейту рознь, какие-то дольше, какие-то быстрее обрабатываются

какие-то можно перемешивать, какие-то нет :)

так и есть, просто апдейт апдейту рознь, какие-то дольше, какие-то быстрее обрабатываются

Это да, но горутины выручают тем, что пока что-то тяжёлое делается для одного юзера, другой не будет ждать

а где у тебя тут про "одного" юзера?

идет тебе три команды

add add done

ты их запустил в горутины, получил add done add

или done add add

правда это только под нормальной нагрузкой будет заметно :)

ты их запустил в горутины, получил add done add

А, ну здесь да, уже ВНУТРИ кейса с сообщениями надо как-то блочить и распределять, это да

дык

плюс можно упереться во время отправки

плюс можно упереться во время отправки

В плане?

телега далеко не всегда отвечает быстро на твой sendMessage

бывает 999ый перцентиль до 7-10 секунд доходит

телега далеко не всегда отвечает быстро на твой sendMessage

Еслис сервак говно, то это да. И если ты не юзаешь вебхуки

бля

не я, а их сервер

POST

ответ на него может быть до 7 секунд , на 999

С их серверами никогда проблем не было. Всё мгновенно.

нагрузки у тебя нет :)

или мониторинга

нагрузки у тебя нет :)

У меня инлайн-поиск по картинкам. Пара сотен постоянных точно есть.

или мониторинга

Я всё тречу

ответ на него может быть до 7 секунд , на 999

По-моему это только для инлайна

вот так выглядят периодические "работы" на телеге

С сообщениями вообще не суть важно. Но если бот очень молчаливый и только кушает сообщения, не отвечая в ответ на кучку сообщений, то телеграм тебе в апдейтах будет сообщать об этом

ну я их так называю.. :)

просто на 2 часа все тупить начинает пару раз в неделю

с 800мс до 7-10 секунд 99 перцентиль и 150мс - 800 мс 75-ый

просто на 2 часа все тупить начинает пару раз в неделю

У меня аптайм две недели было. Боте если и падает, то исключительно из-за процесса качки изображений.

это не падение

это не падение

У меня именно падение процесса в докере

Не умею я пока нормально оперировать загрузкой файлов без проблем. ?

На прошлой неделе куча популярных ботов отвалилось, хрен знает почему.

А мой работал.

ERROR: S client not available

AWS ?

неделю назад не знаю, знаю почему отвалилось 21-ого февраля :)

Или это было на позапрошлой

Или это было на позапрошлой

Ну вот где-то в это время

неделю назад не знаю, знаю почему отвалилось 21-ого февраля :)

Почему?

AWS ?

Не-а. Какой-то местный дешёвенький сервер

в телеге добавили дополнительные валидации на switch_pm_parameter

и те инлайны что там слали фуфло всякое стали получать ошибку START_PARAM_INVALID

в телеге добавили дополнительные валидации на switch_pm_parameter

О, не уж-то пофиксили багу?

багу?

хз

Когда клик по свичу в канале заполняло поле ввода под кнопкой

Не дай бог ты фокус с него потеряешь - потом хрен уберёшь

это вообще к телеге никакого отношения не имеет

это клиентские части же

кто как наговнокодил клиента так и мучается

я тебе про апи говорю сервеное :)

а ты мне клик по свичу

Я не выспался просто

нуок, а я как раз пошел спать.

@mak_tu в общем норм либа и разработчик ее (Syfaro) хорошо идет на контакт, в телеге есть канал.

На нагрузках до 10-15 запросов в секунду даже не парься, выше придется чуть напильничком подпиливать

Все уже видели? http://www.tapirgames.com/blog/golang-syntax-sugars-and-exceptions

@schors

@schors

усе уже

усе уже

хорошо

?

шустро