Https://Pastebin.Com/DugNGmyP Кто-То может подсказать Почему код после 24 строки не исполняется?

Код конечно ужасный, но если по существу, скольким юзерам идёт рассылка?

7r

блять блять блять

Твой выход

Закидайте меня палками Но дайте понять Где я все ломаю

кто то еще юзает .format? ого...

Проблема в том что эту хуйню нет смысла чинить Надо писать заново

Тебя только это смутило? И что в format такого?

не только, я просто его заметил. ну типо не проще дописать f перед строкой и не париться?

Почему global couter

Ты запускаешь 7 тысяч задач "параллельно" на одном ядре, в каждой из которых ждёшь от 0 до 8 секунд и что-то ещё отправляешь Всё хорошо продумал?

Не всегда это приемлимо Это не совсем одно и тоже

а чем разница? обьясните если тупой

Если говорить не о 7к паралельных задач А то что происходит дальше Почему исполнение функции не закрывается?

Semyon Bagrych

https://t.me/aiogram_ru/1247796

_ = gettext f"{_("hello")} "{}".format(_("hello")) В первом случае gettext вызовется один раз при инициализации Во втором случае будет вызываться каждый раз

await write_to_file(data_user) Это как ?

После 24 строки код не исполянется Какая разница что в 26?

await asyncio.gather(*coros) Так он ждёт

Попробуй запустить тоже самое с парой юзеров

На 8 штук оптравило

Тогда https://t.me/aiogram_ru/1249647

Если это рассылка то залупа а не совет

Друг Все проще оказалось в user.id_user none уходило Ошибка останавливала исполнения этого говнокода Всем спасибо Хорошего вечера

Можно пояснения? Привет!

По лимитам обосреться до 100

А если распределить запуск тасков по времени? В случае достижения определенного значения - переносить таску в конец выполнения.

У тебя user_id может бить None ?

Оказывается да Не я писал Фиксы прост

Может тогда лучше последовательно соблюдая лимиты и не париться?😁

Ну смотри. Если у тебя малое количество юзеров, то в общем смысле ты и циклом пройтись можешь, там очень тяжко попасть под лимиты. Но предположим, тебе необходимо сделать рассылку на большое количество юзеров, и чтобы тебя удовлетворяло время отправки. Как тогда ускорить отправку сообщений рассылки?

Так я ничего не советовал ...

На любое. Лучше последовательно и не спеша. Что бы боту не мешать. Лучше одному человеку сообщения из рассылки прийдёт на 3-5секунд позже(он его не ждёт) чем не прийдёт человеку который сейчас пользуется ботов и ждёт сообщение

У меня приходит оповещение о погрешностях. Оно может приходить часто, но само оповещение нужном не всем. Предполагаем, что оно приходит каждый час, всего пользователей порядка 5 тысяч. Чисто технически, если последовательно отправлять, то они не увидят вовремя нужное оповещение. Я не про рекламные рассылки и т.д. и т.п., а о тех, на которых и построена логика самого бота.

Ну тут земля пуховиком. Лимиты тг.

Мы хотим отправлять 2 раза в секунду. Ты можешь контролировать с погрешностью в районе 5% при ок соединении количество отправленных ботом сообщений. Мы загоняем таску под сон так, чтобы упорядочить все отправления пользователям при скорости 2msg/s. И перед тем, как отправить сообщение пользователю, ты проверяешь количество отправленных ботом сообщений. Если они уже 20+, то перетаскиваешь таску в конец костыльной очереди. Мы прогоняли пару раз такой костыльный код, с нагрузкой, ни разу не выкинуло за лимит. НО: 1) это явно не верный подход, так как такие задачи каким-либо образом уже решались за счет мб Celery и т.д.; 2) каждая таска запускается одновременно фактически, а это значит, что при N кол-ве рассылок, у тебя изначально будет N одновременно запущенных функций, однако со скорость кол-ва отправок в секунду оно будет уменьшатся.

А что если таска будет попадать за те 20+ несколько раз подряд с длинной очередью?

при каких ситуациях мы это допускаем?

Да любых. Много людей пользуется ботом сейчас

Ну так смотри. Каждый раз, когда пользователь получает сообщение от бота, мы ведь можем это фактически посчитать. Разве нет?

И что нам это даст?

Подсчет запросов в тг, чтобы не улететь в лимиты

Если мы знаем количество уже отправленных сообщений пользователям, то мы ведь можем это проверять при отправке сообщения-уведомления. Разве нет?

Так это твои 20+ ещё меньше будут и в конец тачки будут улетать чаще

Мы провели тесты при разных нагрузках и разных возможных ситуациях. Погрешность в 4,63% в среднем при 17 разных проверках. Грубо говоря, предполагали 300 секунд отправки полной, но за 312 секунд +- все отправлялось.

Ты выше указал человеку на 7к "параллельных" функций. Насколько это критично по итогу?