Так, это всё отлично, но я спать. Спасибо за советы, Паша, Артем, Алекс, всем спок!

Ну и последний вопрос: как обрабатывать быстро много поступающих сообщений/обновлений? Мне нужно быстро отправить ответ юзеру и записать в БД его меседж.

Ну и последний вопрос: как обрабатывать быстро много поступающих сообщений/обновлений? Мне нужно быстро отправить ответ юзеру и записать в БД его меседж.

Через очередь пусти.

Fire and forget.

А вообще если это по поводу бота в телеге - то лучше вебхуки привязать.

Чем дёргать getUpdates.

А вообще если это по поводу бота в телеге - то лучше вебхуки привязать.

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

Тем более через очереди пусти, тебя же положить могут.

Через очередь пусти.

Записал, завтра изучу. Спасибо.

Соединение с базой не открывай на приёме.

Я 5000 сообщений боту отправлю.

И он упадёт.

Так, это всё отлично, но я спать. Спасибо за советы, Паша, Артем, Алекс, всем спок!

спок

Fire and forget.

Ну и последний вопрос: как обрабатывать быстро много поступающих сообщений/обновлений? Мне нужно быстро отправить ответ юзеру и записать в БД его меседж.

очередь.

Т.е. мне нужно все обновления закидывать в очередь. А как вообще реализуется очередь и как её обрабатывать?

LPUSH -> BLPOP

Собственно, вот так

Т.е. мне нужно все обновления закидывать в очередь. А как вообще реализуется очередь и как её обрабатывать?

Мы закидываем в Redis например.

Собственно, вот так

Только BRPOP, я ошибся.

LPUSH - пульнуть в список слева.

BRPOP - взять справа.

Ну да, или RPUSH

А то если LPUSH BLPOP - это FIFO.

Ну да, или RPUSH

Именно.

А то "хвост" собираться будет.

?

Ещё нужно смотреть в сторону BRPOPLPUSH.

Если у тебя какие-то вычисления которые могут оборваться.

Т.е. мне нужно все обновления закидывать в очередь. А как вообще реализуется очередь и как её обрабатывать?

тысячи их! например, можно на базе массива. или на базе collections.deque

Т.е. мне нужно все обновления закидывать в очередь. А как вообще реализуется очередь и как её обрабатывать?

Один воркер принимает сообщения и пушит в очередь, другой их оттуда достает и обрабатывает

Один воркер принимает сообщения и пушит в очередь, другой их оттуда достает и обрабатывает

У меня один обрабатывает, а 16 закидывает.

?

Но это потому что дохуя обновлений приходит.

Один тупо не справляется.

Например флуд какой-то идёт и у тебя и очередь может заткнуться.

А популярных ботов часто спамят.

Я видел как некоторые собирают всех ботов в одну группу.

И начинают спамить.

А юзаешь какой-то фреймворк ботовый?

Это вроде как чтобы всех сразу положить.

А юзаешь какой-то фреймворк ботовый?

Они не нужны, я вообще не понимаю их смысл.

А юзаешь какой-то фреймворк ботовый?

https://github.com/eternnoir/pyTelegramBotAPI

Bot API элементарное.

sendMessage я могу отправить без фреймворка.

Зачем фреймворк - не ясно.

Зачем фреймворк - не ясно.

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

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

Мне кажется, это overhead даёт определённый.

К тому же я уверен, что там объектно-ориентированный интерфейс.

Это ещё к overhead'у.

А мне (лично мне) нужно просто сообщения в очередь прохуяривать.

Как можно быстрее.

Видоизменяя входящий массив только минимально.

Т.е. я сообщения обрабатываю по сути уже в демоне.

Который с очередями работает.

А endpoint "голенький".

Там только persistent соединение с Redis и минимальная обработка входных.

(чтобы мусор не попал на всякий случай)

Я подумываю даже минимальную обработку перенести тоже на воркер, чтобы максимально снизить любые нагрузки на endpoint.

Кстати сообщения отправляются не из воркера, а прямо с endpoint'a, потому что, опять же, скорость.

Резюмируем: - все входящие в очередь отдельным воркером - несколько воркеров для обработки сообщений из очереди - из очереди же сообщения попадают в постоянное хранилище

Пока он долетит в очереди - пройдёт секунда, может две.

Резюмируем: - все входящие в очередь отдельным воркером - несколько воркеров для обработки сообщений из очереди - из очереди же сообщения попадают в постоянное хранилище

Да.

Python для обработки данных позволяет создавать по процессу на ядро.

Через multiprocessing или multithreading я уже не помню.

Вот я как раз создаю по воркеру на ядро.

ERROR: S client not available

Есть еще threading

Вот я как раз создаю по воркеру на ядро.

Можно ли как то приблизительно понять какой сервер мне понядобится?

Есть еще threading

GIL

Можно ли как то приблизительно понять какой сервер мне понядобится?

Смотря сколько тебе запросов в секунду обрабатывать нужно.

треды ускорят вас только на i/o

У меня просто только большие железяки, я не измерял на маленьких.

http://geekforbrains.com/post/after-a-year-of-nodejs-in-production

Предпологается пока что около 1000 юзеров/сутки

Предпологается пока что около 1000 юзеров/сутки

Я столько в минуту принимаю примерно, чуть меньше.

Лол, а мы тут уже придумали хайлоад

http://geekforbrains.com/post/after-a-year-of-nodejs-in-production

Нет, спасибо:) Не люблю javascript, после python хочу изучить СИ

наш скромный бот проверяет кучу всего на вирусы.

1000 юзеров в сутки выдержит обычный VPS.

Я думаю.

Это мало же.

1000 юзеров в сутки выдержит обычный VPS.

Обычный это 2х-4х ядерный, сколько ОЗУ?

Предпологается пока что около 1000 юзеров/сутки

Вообще можешь забить на очереди с таким количеством юзеров

Обычный это 2х-4х ядерный, сколько ОЗУ?

Для 1000 пользаков в сутки я думаю хватит 1-2 GB RAM.

Это мало же.

Для меня много пока что:)

Скорее и 1 хватит.

Там ОЗУ не нужно.

Тебе процессор нужен.

Ты будешь с базой работать.

Я забыл.

Так что оперативка тебе в принципе особо не нужна.

А вот процессор и т.д. - очень важно.

зачем там cpu?

Вообще можешь забить на очереди с таким количеством юзеров

Кстати хороший совет дали.

зачем там cpu?

MongoDB и MySQL жрут CPU как ссаные мрази.

MongoDB вообще любит на 100% по рандому забивать процессор.

Какой ему понравится.

Вообще можешь забить на очереди с таким количеством юзеров

А если все 1000 будут сразу писать друг другу через бота? + задача есть предусмотреть масштабируемость в будущем при возрастании нагрузки