помнится для джаббера вообще в один поток все гоняли. И не парились, и работало все шустро, на сколько позволял канал и сервер

если не связывать их никак, то легко получится масштабировать любую часть

а что с интерваллом который юзверь задаёт

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

я бы так делал

не знаю, мб и на 3 - принимает инфу от юзеров, включая изменения конфигурации, рассылает юзерам согласно конфигурации и собирает инфу с рсс

так более муторно и больше кода уже выйдет

ой ли

не знаю, мб и на 3 - принимает инфу от юзеров, включая изменения конфигурации, рассылает юзерам согласно конфигурации и собирает инфу с рсс

две - одна работает с телеграмом, дугая парсит рсс фиды

нефик плодить сущности

Рассылка и сбор разные вещи, сбор завязан на события, приходящме извне, рассылка - на собственные

Давайте ещё базу воткните, очереди запилите, микросервисы и на каждый по контецнеру

Так да, между ними база

Давайте ещё базу воткните, очереди запилите, микросервисы и на каждый по контецнеру

ну, скулайт можно, можно и без него

Давайте ещё базу воткните, очереди запилите, микросервисы и на каждый по контецнеру

в оперативе всё хранить предлагаешь? и фиды, и настройки? :)

Мб просто подскажете человеку как сделать как хочет она?)

Сложность-то при этом не увеличивается

Мб просто подскажете человеку как сделать как хочет она?)

нет. это не в этом чатике. В даный момент ты наблюдаешь мозговой штурм. А делать выводы - ее работа

Мб просто подскажете человеку как сделать как хочет она?)

да тут уже вроде пытались, но человек хочешь с async/await, но не понимает куда их применять. хотя вроде тут уже разжовывали всё

Это все нужно будет многожды перезапускать без потери данных

Конечно нужна база

Конечно нужна база

можно в json хранить

Можно, но это тоже база

Просто хреновая

все зависит от нагрузки

Ну может быть и не хреновая, а такая же)

Всегда синкаемся с файлом при изменении конфига

в json ты всегда будешь вынужден загружать всё, даже если тебе нужно только две записи.

Без нагрузки это сработает

У меня был такой бот

в json ты всегда будешь вынужден загружать всё, даже если тебе нужно только две записи.

а кто сказал что все будет в одном файле?

ну и в итоге в чём профит?

На 150 юзеров примерно, все работало ок.

сложность та же, по скорости - хуже.

Но это тоже база, с тем же скулайтом никакой разницы

с этим async уже, мне кажется, синдром молотка развился у людей. всё гвозди :)

это просто очень удобный инструмент для большинства задач

сложность та же, по скорости - хуже.

какая разница, когда бот висит на сервере, где твердотелки в качестве hdd

ну да. и память давай не экономить, на серверах куча её.

ну да. и память давай не экономить, на серверах куча её.

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

ну вот процес лишний - это лишние сущности, а куча файлов, гемор с хранением фидов, вместо одного небольшого файла sqlite - это нормально :)

В чем разница с монгой?

если там данных на 100 кб, то вообще пофиг где и как хранить.

Асинхронщина тут не к месту как мне кажется. Три процесса - самое оно. Один слушает юзверя, другой парсит ленты, третий считает интервалы и пинает юзверя.

поддерживаю, плюс меньше проблем если один из процессов упадет

ну вот процес лишний - это лишние сущности, а куча файлов, гемор с хранением фидов, вместо одного небольшого файла sqlite - это нормально :)

проге и файловой системе пофик вообще на количество файлов, если конечно ты не юзаешь оооочень старое Г в качестве фс.

я просто не могу понять в чём смысл и профит использования текстовых файлов вместо компактной базы данных

?!? def post_on_channels(_content): for channel in channels: bot.sendMessage(channel, _content) await asyncio.sleep(interval)

я просто не могу понять в чём смысл и профит использования текстовых файлов вместо компактной базы данных

Единственный - в человекочитабельности

я просто не могу понять в чём смысл и профит использования текстовых файлов вместо компактной базы данных

никакой

я просто не могу понять в чём смысл и профит использования текстовых файлов вместо компактной базы данных

ну бд с ее транзакциями не всегда нужно

?!? def post_on_channels(_content): for channel in channels: bot.sendMessage(channel, _content) await asyncio.sleep(interval)

async def

?!? def post_on_channels(_content): for channel in channels: bot.sendMessage(channel, _content) await asyncio.sleep(interval)

либо так, либо через gather, как я выше написал

bot.sendMessage(channel, _content) по моему и эту штуку не плохо было бы сделать асинхронной

bot.sendMessage(channel, _content) по моему и эту штуку не плохо было бы сделать асинхронной

оно и так асинхронно

ну бд с ее транзакциями не всегда нужно

так никто же не заставляет использовать не нужное.

оно и так асинхронно

это ты где увидел?

оно и так асинхронно

разве? вроде как эти две строки for channel in channels: bot.sendMessage(channel, _content)по другому надо написать чтобы было асинхронно

разве? вроде как эти две строки for channel in channels: bot.sendMessage(channel, _content)по другому надо написать чтобы было асинхронно

Да. причём channels тоже не простой список должен быть https://www.python.org/dev/peps/pep-0492/#asynchronous-iterators-and-async-for

разве? вроде как эти две строки for channel in channels: bot.sendMessage(channel, _content)по другому надо написать чтобы было асинхронно

ну да. чет я и сегодня в перегрузе. Проход по каналам там надо разместить отдельно, а в этой функе оставть только сэнд

типа так: async def post_shit(channel, timeout): while True: post(channel, “shit”) await asyncio.sleep(timeout) async def schedule(workers): await asyncio.gather(workers) if __name__ == “__main__”: loop = asyncio.get_event_loop() workers = [post_shit(c, t) for c, t in CHANNELS] loop.run_forever(schedule(workers))

не ну так то можно и простым списком сделать, потом заюзать генератор c gather

не ну так то можно и простым списком сделать, потом заюзать генератор c gather

++

именно это и предложил

а там люди процессы какие-то хотят спавнить

post(channel, “shit”) вот это желательно должно быть асинхронным

post(channel, “shit”) вот это желательно должно быть асинхронным

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

я почти уверен, что пока нет

я почти уверен, что пока нет

переписать либу)

ERROR: S client not available

хотя. вроде уже переписывали

переписать либу)

как вариант :)

telepot имеет разные версии ботов, обычный и асинхронный так что тут особо можно не парится

await asyncio.sleep(timeout) кажется что и это лишнее

надо сырки смотреть

await asyncio.sleep(timeout) кажется что и это лишнее

это период, с которым надо постить

не, ну там проде можно через таймаут, как в джаваскрипте

но так императивней и без коллбэк хелла

?!? def post_on_channels(_content): for channel in channels: bot.sendMessage(channel, _content) await asyncio.sleep(interval)

@Enchantner тогда ты неправильно переписал, потому что в коде одна новость на несколько каналов рассылается\

поэтому и задержки не нужны

@Enchantner тогда ты неправильно переписал, потому что в коде одна новость на несколько каналов рассылается\

с одним периодом на все каналы?

ну да

@Enchantner тогда ты неправильно переписал, потому что в коде одна новость на несколько каналов рассылается\

нет. считай что у каждого канала свой фид

ну тогда перенести таймаут внутрь schedule

и цикл бесконечный

ну тогда перенести таймаут внутрь schedule

аее, да мы дрим тим) задача решена, дайте следующую:D

в любом случае, код сложнее не станет

не надо никаких трех процессов, вот, две функции и все

ты сейчас в двух функциях описал одну часть задачи :) рассылку. А нужно ещё принимать сообщения от пользователя и парсить фиды.

ты сейчас в двух функциях описал одну часть задачи :) рассылку. А нужно ещё принимать сообщения от пользователя и парсить фиды.

ты сейчас описал еще две функции простые

Простые. по отдельности. Запихни сейчас всё это в своё решение и посмотри, не проще ли будет всё сделать отдельными сервисами. Особенно когда нагрузка пойдёт :)

Простые. по отдельности. Запихни сейчас всё это в своё решение и посмотри, не проще ли будет всё сделать отдельными сервисами. Особенно когда нагрузка пойдёт :)

ну, если у телеграма асинхронные биндинги и парсинг фида делается быстро - то нагрузка тут вообще нипочем

просто спавним несколько тасков и все

периодических

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

А теперь представь, что парсинг не быстрый, фидов - 500 штук и пользователей у тебя уже 1500. Реально считаешь, что один процес с асинхронщиной будет справляться быстрее трёх с учётом многоядерности?

А теперь представь, что парсинг не быстрый, фидов - 500 штук и пользователей у тебя уже 1500. Реально считаешь, что один процес с асинхронщиной будет справляться быстрее трёх с учётом многоядерности?

ну смотри, у меня есть таска, которая парсит фид и таска, которая рассылает апдейты пользователям

если рассылка пользователям делается параллельно, а парсинг фида занимает сильно меньше времени, чем промежуток между рассылками (а это, скорее всего так), то то, что они бегут в одном эвентлупе - вообще не проблема

и да, оно будет быстро

если рассылка пользователям делается параллельно, а парсинг фида занимает сильно меньше времени, чем промежуток между рассылками (а это, скорее всего так), то то, что они бегут в одном эвентлупе - вообще не проблема

Можно ещё планировщик заданий запилить)

Можно ещё планировщик заданий запилить)

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

вот в этом и проблема - сплошные допущения и если. а если справляться перестанет - как масштабировать будешь?