Size: a a a
2020 July 24
ЕП
Масштабировать можно и с полингом, другое дело что с вебхуками проще
А как масштабировать с поллингом?
Т
да и какое может быть серьезное масштабирование, когда присутствуют лимиты? 🤔
ЕР
Разве там не дороже?
бесплатно через ajax
ЕП
не увидел чего-то существенного про масштабирование. Они выделили два натянутых плюса - избавление серверов телеги от постоянной дрочки в стиле осла из шрека «уже приехали?», а также нет нужды писать собственный механизм обработки кучи апдейтов (но мы и так его не пишем, оно уже написано за нас)
Первый аргумент - мой личный, второй - со ссылкой на источник
Т
Первый аргумент - мой личный, второй - со ссылкой на источник
дай навигацию по источнику, где именно искать. Портянка то немаленькая
ЕП
дай навигацию по источнику, где именно искать. Портянка то немаленькая
Да самое начало же
ЕП
Да самое начало же
Т
ну, а первый «аргумент» это предположение, оно же ни на чем не стоит? Опытным путем получено такое заключение, или чуйка?
Т
так а где про масштабирование то? Речь тут про разность между способами доставки обновлений
Ты читал как работает лонг поллинг? Много не потеряешь
ЕП
так а где про масштабирование то? Речь тут про разность между способами доставки обновлений
Блэт, ещё раз: про масштабирование – это лично мой аргумент, он не написан по ссылке выше (я его даже первым привел, чтобы не было путаницы). Нет, nein, no, не-а. Как ещё-то написать?
Да, чуйка, конечно. Но основанная на ряде предположений.
На обработку событий уходит какое-то время. В идеальном мире обработка одних событий никак не влияет на другие. К сожалению, в реальности это не так. Поэтому когда у тебя много запросов, то одним из вариантов повышения отзывчивости может стать масштабирование процессов бота, скрытых за одной проксей типа nginx. Я не представляю, как это сделать на поллинге, но на вебхуках – очень просто, если твой бот не хранит в своем коде никаких состояний, а выносит их наружу
Да, чуйка, конечно. Но основанная на ряде предположений.
На обработку событий уходит какое-то время. В идеальном мире обработка одних событий никак не влияет на другие. К сожалению, в реальности это не так. Поэтому когда у тебя много запросов, то одним из вариантов повышения отзывчивости может стать масштабирование процессов бота, скрытых за одной проксей типа nginx. Я не представляю, как это сделать на поллинге, но на вебхуках – очень просто, если твой бот не хранит в своем коде никаких состояний, а выносит их наружу
Т
Блэт, ещё раз: про масштабирование – это лично мой аргумент, он не написан по ссылке выше (я его даже первым привел, чтобы не было путаницы). Нет, nein, no, не-а. Как ещё-то написать?
Да, чуйка, конечно. Но основанная на ряде предположений.
На обработку событий уходит какое-то время. В идеальном мире обработка одних событий никак не влияет на другие. К сожалению, в реальности это не так. Поэтому когда у тебя много запросов, то одним из вариантов повышения отзывчивости может стать масштабирование процессов бота, скрытых за одной проксей типа nginx. Я не представляю, как это сделать на поллинге, но на вебхуках – очень просто, если твой бот не хранит в своем коде никаких состояний, а выносит их наружу
Да, чуйка, конечно. Но основанная на ряде предположений.
На обработку событий уходит какое-то время. В идеальном мире обработка одних событий никак не влияет на другие. К сожалению, в реальности это не так. Поэтому когда у тебя много запросов, то одним из вариантов повышения отзывчивости может стать масштабирование процессов бота, скрытых за одной проксей типа nginx. Я не представляю, как это сделать на поллинге, но на вебхуках – очень просто, если твой бот не хранит в своем коде никаких состояний, а выносит их наружу
- не увидел чего-то существенного про масштабирование
- Первый аргумент - мой личный, второй - со ссылкой на источник
- так а где про масштабирование то?
- Блэт, ещё раз: про масштабирование – это лично мой аргумент, он не написан по ссылке выше
🤔 тогда к чему вообще был этот «аргумент» по ссылке на документацию?
- Первый аргумент - мой личный, второй - со ссылкой на источник
- так а где про масштабирование то?
- Блэт, ещё раз: про масштабирование – это лично мой аргумент, он не написан по ссылке выше
🤔 тогда к чему вообще был этот «аргумент» по ссылке на документацию?
ЕП
Пожалуйста, читай не жопой
ЕП
- не увидел чего-то существенного про масштабирование
- Первый аргумент - мой личный, второй - со ссылкой на источник
- так а где про масштабирование то?
- Блэт, ещё раз: про масштабирование – это лично мой аргумент, он не написан по ссылке выше
🤔 тогда к чему вообще был этот «аргумент» по ссылке на документацию?
- Первый аргумент - мой личный, второй - со ссылкой на источник
- так а где про масштабирование то?
- Блэт, ещё раз: про масштабирование – это лично мой аргумент, он не написан по ссылке выше
🤔 тогда к чему вообще был этот «аргумент» по ссылке на документацию?
Т
Пожалуйста, читай не жопой
какой жопой?
я спросил каким хуем на одной смысловой ступеньке встали рядом способ доставки обновлений и мнимая масштабируемость, ты приводишь какой-то свой довод и ссылку, а затем оказывается что ссылка была вообще о другом? ЯННП
я спросил каким хуем на одной смысловой ступеньке встали рядом способ доставки обновлений и мнимая масштабируемость, ты приводишь какой-то свой довод и ссылку, а затем оказывается что ссылка была вообще о другом? ЯННП
ЕП
Так понятнее? Или надо прям номерным списком сделать?
Т
Так понятнее? Или надо прям номерным списком сделать?
мне всё еще не ясно к чему была эта ссылка на доку. Я по ней должен был почитать разницу между способами доставки, или что?
ЕП
Ладно, я понял. Сейчас будет совсем наглядно:
Т
ты же отталкиваешься от нее разговаривая на тему масштабируемости и кол-ва юзеров