Ajax, web 2.0 и альтернатива запросам по таймеру

Во-первых, не обязательно дергать раз в минуту. Можно чаще.

Во-вторых, google websockets. Сейчас это популярно.

Django не может в websockets. Придётся поднимать рядом tornado и синхронизировать через redis

Во-первых, не обязательно дергать раз в минуту. Можно чаще.

Все равно это будет далеко от realtime, да и на нагрузке это плохо отразится.

Во-вторых, google websockets. Сейчас это популярно.

Стандартизацию еще не прошло, как я понимаю, а в контактике при наборе сообщения уже давно появлялось уведомление «вам печатают». Что Дуров там мог использовал?

Возвращаясь к вебсокетам. При вставке в БД запись я должен буду сообщить об этом django, далее надо будет пройтись по открытым сокетам и по ним сообщить о событии. Правильно?

Django не может в websockets. Придётся поднимать рядом tornado и синхронизировать через redis

https://habrahabr.ru/post/211094/

Не то?

Обратите внимание, что Django в этом примере не используется вообще. Tornado выдает статический HTML-файл и передает все вебсокет-запросы django-websocket-request, в котором уже и происходит вся магия.

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

Правильно предполагаю?

Возвращаясь к вебсокетам. При вставке в БД запись я должен буду сообщить об этом django, далее надо будет пройтись по открытым сокетам и по ним сообщить о событии. Правильно?

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

Все равно это будет далеко от realtime, да и на нагрузке это плохо отразится.

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

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

В принципе, тебе django может вообще быть не нужна. Делаем single page application целиком на ajax, на стороне сервера какой-нить aiohttp. Ну и плюс queue и Event — то что тебе нужно для всяких pub/sub итп. Для ORM можно какой-нить sql alchemy итп, много их. Можешь даже с nosql поиграться, для чата сойдёт.

Т.е., подписываешься на события и вешаешь обработчики типа «отослать всем сообщение в чат» и «сохранить сообщение в БД».

миллиард клиентов, долбящихся раз в секунду за обновлениями чята, не вешали сервер.

Не надо так, на стороне клиента ресурсы не резиновые (проц/канал).

Какие ещё проц/канал, когда речь идёт об одном POST запросе в секунду?
У тебя клиенты выходят в интернет с механического калькулятора что ли?

Я так понял отображение сообщений из чата это не единственная функция сайта. Стоит задача прикрутить к уже имеющемуся сайту новую фишечку. Хотя конечно можно реализовать её отдельно от джанги, хотя-бы и айфрэймом вставить.

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

man event-driven

У тебя клиенты выходят в интернет с механического калькулятора что ли?

У меня батарея в ноуте садится за час если вкладки не заморозить. Причём, я как-то начал выяснять что отжирает и ужаснулся — всякие клауды-шмауды, статистика, реклама, встроенные чаты, уведомления... Сайты даже перемещение мышки по ним трекают и на каждое событие весело рапортуют на какой-нить mc.yandex.ru. Да даже просто рапортуют «смотрите, у него открыта вкладка». И речь не идёт о развлекательных ресурсах, блокировщик рекламы стоит.

Пример «тупой» вкладки которая постоянно что-то делает с гугловыми либами: http://www.power-eetimes.com/content/how-extend-power-supply-droop-compensati...

Комет был сто лет назад.

До появления вебсокетов все комет-технологии базировались все на том же опросе.

Что там придумали бородатые дядьки за то время, пока я спала?

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

Какое к чертям ядро процессора на сто запросов в секунду?
Выброси нахер свои счёты и купи себе хотя бы ламповый калькулятор.

И, во-вторых, ничто не мешает как скрипту прекращать запросы при неактивном окне, так и самому браузеру останавливать все скрипты в неактивных вкладках.

статистика, реклама, встроенные чаты

на каждое событие весело рапортуют на какой-нить mc.yandex.ru

блокировщик рекламы стоит

Во-первых — херовый у тебя блокировщик стоит.
Во-вторых — POST запросы не сажают батарею, если их не криворукие ангулярные кулхацкеры пишут.

Пример «тупой» вкладки которая постоянно что-то делает с гугловыми либами

Пример результата грамотной настройки блокировки всякого ненужного говна в браузере:

The resource at "http://www.google-analytics.com/analytics.js" was blocked because tracking protection is enabled.

Разве это проблема? Нет никакой нужды для всего на свете использовать django.

Вопрос не в ста запросах в секунду. А в куче страниц написаных интернациональными JS-индусами которые раз в секунду делают ненужное чёрт знает что.

P.S. мои счёт модели E8200 меня всецело устраивают. И мне не то что жалко денег на счёты поновее, мне жалко времени на то что-бы соорудить удобную докстанцию для уже имеющихся счёт поновее (модели iсколько-то-там, вечно забываю, а жопу поднимать лень).
Если-бы у меня была какая-то весомая причина для, я-бы конечно озаботился. Но «дать возможность вебмакакам и дальше не знать про вебсокеты, лонгпулинг, мышление и другие передовые технологии» к таковым, по моему мнению, не относится.

P.P.S. вот по поводу «во-вторых». Оно где-то реализовано? Оно так конечно правильно, только нужна ручка позволяющая делать нужные вкладки незамораживаемыми.

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

Во-первых, внезапно :-) Во-вторых, и да :-) В-третьих, вменяемо :-) В-четвёртых, от слова «совсем» :-) И т.д. :-)

Сайт на django уже есть и он работает. И игровой чат там далеко не самое главное. Просто необходимо реализовать фичу «правильным» способом.

Запрашивать по таймеру дельту некошерно, ибо неэффективно и не соответствуют требованию «реалтаймовости». Так что использование вебсокетов через костылики redis и tornado кажется разумным решением.

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

В фоновых вкладках браузер автоматом ограничивает частоту подобных запросов.

Сайт на django уже есть и он работает. И игровой чат там далеко не самое главное. Просто необходимо реализовать фичу «правильным» способом.

А что мешает совмещать джанго и не джанго? Большие проекты сплошь состоят из микросервисов, на чем только не написанных.

А что мешает совмещать джанго и не джанго? Большие проекты сплошь состоят из микросервисов, на чем только не написанных.

Можно. Потому и интересуюсь возможными решениями.

Во-первых вебсокеты нагружают процессор сильнее пост-запросов, внезапно.

[citation needed]

Во-первых вебсокеты нагружают процессор сильнее пост-запросов, внезапно.

Просто висящий и ждущий сообщения от сервера? Попахивает быдлокодом со стороны разработчиков браузеров. Хотя я почему-то не удивлён.

В-третьих просто не надо открывать в фоновых вкладках индусские говносайты

Ещё скажи советскую прессу до обеда не читать…

Попахивает

В обеих случаях не происходит ничего особенного, но в случае вебсокета оно ждёт сообщения постоянно и без перерывов, а в случае POST-запроса оно просыпается на несколько миллисекунд и засыпает обратно на тысячу.
С потребительской точки зрения и то и другое ничего не потребляет, с фактической сокеты гибче, но немножко жручей.

JS код ждёт когда его пнёт браузер, браузер ждёт когда его пнёт ядро, ядро ждёт когда ему в сетевой интерфейс прилетит соответствующий пакет. Откуда тут взяться потреблению в простое?

JS-код, вестимо, как-то неправильно ждёт

Это тот самый JS который весь такой божественно асинхронный и колбэчный?

Всё равно пахнет бредом. Можно линк на цифры?

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

Информация более не актуальна.

Long polling/SSE. Лучше всего конечно сделать отдельную шнягу для рассылки сообщений.

POST запросы не сажают батарею

Они сажают хотя бы тем что не дают процу спать. Другая проблема у меня — какие-то вкладки вызывают постоянную перерисовку что в хроме отражается в потреблении GPU process. Как бы вкладки ничего не грузят, но в top 35% одного проца загружено.