Комментарии 35
как устроен самый популярный Channel Layer для продакшена — Redis.
Мне было всегда интересно, почему? Redis же просто ужасен как MQ, почему он так популярен то?)
Очень простой, очень быстрый. Простота развертывания и использования компенсирует ужасность :)
Впервые слышу такое мнение. Чем плох Redis? Если можно, с примерами.
Плох — это не правильное слово, он просто не подходит под Message Queue и вот почему:
1. Он не способен хранить вещи не в памяти. То есть вам нужно, что бы очередь влезла в память, что очень не всегда получается. Более того, если он у вас еще и в персистентном режиме, то после того, как он упадет из-за нехватки памяти, он еще и не поднимется, пока вы его не почистите. У нас такое было в sentry, который по умолчанию запускает celery на redis.
2. Redis не может в нормальный master<->master кластер, вам нужно это делать на стороне приложения или использовать какие-то из redis-совместимых приложений.
1. Он не способен хранить вещи не в памяти. То есть вам нужно, что бы очередь влезла в память, что очень не всегда получается. Более того, если он у вас еще и в персистентном режиме, то после того, как он упадет из-за нехватки памяти, он еще и не поднимется, пока вы его не почистите. У нас такое было в sentry, который по умолчанию запускает celery на redis.
2. Redis не может в нормальный master<->master кластер, вам нужно это делать на стороне приложения или использовать какие-то из redis-совместимых приложений.
Библиотека давно уже есть, игрался с ней в хобби проекте, может быть сейчас как раз глюков поменьше.
Очень странно писать во второй половине 2018 года про channels, а не про channels2, да ещё и как будто про новую библиотеку. На самом деле в channels2 всё архитектурно совсем не так (и намного лучше).
А, увидел что видео с конференцией
Опубликовано: 3 нояб. 2016 г.ну в общем-то вопросы отменяются, хотя всё равно странно.
Это толстый намек на то, что осенью на conf.python.ru мы будем обсуждать channels2. Заходите на огонек!
Хорошая новость: для того, чтобы использовать Django Channels, вам вообще не нужно знать ни Twisted, ни Redis — это все детали реализации. Это будут знать ваш DevOps, или вы познакомитесь, когда будете чинить в три часа ночи упавший продакшен.
Как красиво сказано. Но на самом деле в «детали реализации» вы полезете смотреть уже через 20 минут, когда вам захочется, например, узнать сколько юзеров в группе и через час-два гугления вы поймете что это не поддерживается API вообще и тикет закрыт с пометкой о том что так и надо.
Когда будете гуглить, то учитывайте что 90% примеров в сети и в SO в частности относятся к channels 1.x, в то время как автор уже переписал ее в 2.0 и она, мягко говоря, поменялась. В доках стоит почитать его восторги по этому поводу и порадоваться за него.
Вообще говоря, немного разочаровала эта библиотека, хотя, конечно, принесла много новых вещей. Ждали ее как silver bullet, но она довольно туповата.
Во всех без исключения примерах разбирается «чат» и кроме чата на ней, действительно, что-то реализовать уже потребует некоторых размышлений. Синяя изолента должна быть под рукой.
НЛО прилетело и опубликовало эту надпись здесь
pep8? не думаю
С 14го года не интересовался джангой, она всё также вширь и вширь? Всё больше и больше батареек? А шаблонизатор всё также отстаёт в несколько раз от jinja2 по всем параметрам? ORM думаю тоже не приблизился к уровню SQLAlchemy?
Все верно, можно подключить какой нарвится шаблонизатор, ORM и пользоваться в свое удовольствие.
Какой тогда смысл в джанге? Оторвать от неё куски и лишится всех её плюшек? Взять фреймворк, чтобы там почти всё поменять? Мне, видимо, этого не понять. Я лучше возьму предназначенный для этого фласк или другой микрофреймворк.
Достоинство Django в том, что уже есть готовые решения для практически любой задачи. Не надо изобретать велосипед. А ORM совершенствуется с каждым релизом. Если в первые годы использования Django регулярно приходилось использовать .raw запросы или вообще голый SQL, то внезапно осознал, что не делаю этого уже последние года 4-5.
НЛО прилетело и опубликовало эту надпись здесь
SQLAlchemy и есть ORM.
Не так. У sqla есть слой ORM.
Вот тут уже и я заинтересовалия. «SQL» и «ORM» сами по себе — это названия концепций, но не конкретных реализаций. База данных PostgreSQL реализует концепцию SQL, фреймворк PonyORM реализует концепцию ORM. Что значит «У SQLа слой ORM»?
SQLAlchemy is the Python SQL toolkit AND Object Relational Mapper that gives application developers the full power and flexibility of SQL.
У SQLA есть core (интерфейсы и методы самого низкого уровня, напр. db.query('SELECT * FROM ..')) слой, есть query-builder, а есть ORM. ORM использует query-builder который использует core. Использованием ORM который предоставляет SQLA совершенно не обязательно, можно пользоваться прекрасным query-builder-ом и забыть про ORM совсем. Собственно, многие так и делают.
Закидают меня камнями… Но даже в 2018… Если нет дикой необходимости в асинхронщине и вебсокетах, то стоит на них смотреть только в образовательных целях.
Попробовали у себя на проекте потестировать Django Channels — оказалось, что когда количество подключений в одной группе превышает 200-300 — последние добавившиеся в группу перестают получать сообщения по вебсокету. Это не подходило под наши задачи, вернулись обратно к связке Django+Centrifugo.
А вы не исследовали проблему? В чем проблема была? Какие-нибудь известные тикеты есть на это?
Да, тикет на эту тему есть: github.com/django/channels/issues/1116
Andrew Godwin в нем ответил следующее:
По сути, группа в большей степени предназначена для разных подключений одного пользователя (разные браузеры/устройства). Для большого количества одновременных подключений Channels не подходит (во всяком случае пока). Глубже копать особо не стали, вернулись к прошлому решению на Centrifugo, которое успешно работало у нас несколько лет.
Andrew Godwin в нем ответил следующее:
In general I wouldn't recommend Channels groups for any sort of large-scale work — you should probably roll your own solution if you have more than about 50 concurrent users in any single group, as you'll know the best option to use at your scale.
… Groups is more designed to have hundreds of groups with only a few members in each (i.e. per-user).
По сути, группа в большей степени предназначена для разных подключений одного пользователя (разные браузеры/устройства). Для большого количества одновременных подключений Channels не подходит (во всяком случае пока). Глубже копать особо не стали, вернулись к прошлому решению на Centrifugo, которое успешно работало у нас несколько лет.
Да уж, не очень понятно с этим, конечно, получается… Я с таким не сталкивался, честно говоря (но у меня пока не было кейсов со многими сотнями одновременных асинхронных подключений). Но судя по тикету дело-то совсем не в размере группы (хотя именно об этом там говорят в основном, с пояснением «просто не делайте так»), а вообще в количестве подключений, ту мани опен файлес итд итп? И судя по итогам тикета это вроде как «нормально». Это как так то?
Насколько я понял, проблема возникает именно с группой. То есть, Channels рассылает сообщения участникам группы сравнительно медленно и после 200-300 сообщений рассылающая корутина отваливается по таймауту в 10 секунд.
Каков вообще предел одновременных подключений к Channels трудно сказать, мы в него не успели упереться.
Кстати, Андрей Светлов на PiterPy говорил, что вообще ASGI это костыль и он по своей архитектуре в принципе не может работать быстро. Хотя и отметил, что это неплохое решение для Django из коробки для тех, у кого нет больших нагрузок.
Каков вообще предел одновременных подключений к Channels трудно сказать, мы в него не успели упереться.
Кстати, Андрей Светлов на PiterPy говорил, что вообще ASGI это костыль и он по своей архитектуре в принципе не может работать быстро. Хотя и отметил, что это неплохое решение для Django из коробки для тех, у кого нет больших нагрузок.
Да, кагбэ не хватает какой-то дополнительной истории…
Из-за чего такое происходило-то в итоге?
Из-за чего такое происходило-то в итоге?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Django Channels – ответ современному вебу