Pull to refresh

Comments 34

Статья хорошая, спасибо.
Но, какой классный у вас проект! Блин, однозначно в закладки.
Дествительно, причем и ошибся в прошлом комментарии: Java для бизнес логики, для хранения данных кластер PostgreSQL.
Кстати, информация устарела. Сейчас уже более 17 000 виджетов и комментариев по 10 000 в день.
UFO just landed and posted this here
Я правильно понимаю, что в реальных условиях у вас URL для получения событий это не
http://stream.example.com/sub/1
http://stream.example.com/sub/2

а что-то посложнее, a-la
http://stream.example.com/sub/njnnjnOIUIn8NUInYUG56
http://stream.example.com/sub/bnYUBn789nbn8N90
?
Все зависит от того, какой идентификатор подписчика выбрать. Если хочется просто, то цифры вполне подойдут, если что-то сложнее + небольшая защита от ботов, то njnnjnOIUIn8NUInYUG56, bnYUBn789nbn8N90 — будет лучше.
Ну, я к тому, что простые последовательные числовые идентификаторы можно перебрать и читать данные других юзеров…
>и читать данные других юзеров…

Это-то как раз в любом случае тривиально решается проверкой кукисов, который в любом случае делать надо.
А можно этот тривиальный момент в двух словах описать?
Это же должен делать не nginx, а «сайт», но он в этом процессе не участвует, поэтому ничего тривиального
Да, вполне. Стабильно каждую секунду держит от 10 000 до 30 000 подписчиков. Нагрузочное не делали.
фоллбек на флеш? + надо учитывать, сколько людей из вашей аудиотории сидит на старых браузерах. сколько из них без флеша?
А зачем, если long polling работает отлично!
вебсокет коннекшены дешевле, нет?
А можно вопрос? Я, вот, например, не слышал про PUSH-модуль, который озвучен в статье, но делаю билды NgX с вот этим: pushmodule.slact.net/

Он, разве, не подойдёт? :)
На сколько мне известно, nginx-push-stream-module — это fork модуля о котором вы говорите, с множеством фич, например jsonp.
Как и коллеги из Cackle, мы в Битрикс24 тоже использует данный сервер очередей в продакшене, хорошее решение.
Недавно прикручивали real-time, но с использованием nginx http push module и jquery. Подобного руководства не хватало. Вопрос: при такой логике
if ($this.time === null) {
    $this.time = $this.dateToUTCString(new Date());
}

не возникает проблем когда время на клиенте не совпадает с серверным?
Не совсем понимаю, в action вы ещё раз запускаете poll? readyState меняется один раз, когда документ (сообщение) загружен целиком. После чего надо запускать новый xhr, вы так и делаете?

Чем не устраивает chunked? Есть вот такой вот вариант, использующий onprogress, и не требующий установления повторного соединения после получения каких-либо сообщений.
А каким образом реализована возможность защиты канала, т.е. чтобы левые пользователи не могли подписаться на прослушивание канала?
Возможно несколько наивный вопрос, я в этом абсолютный дилетант. Правильно ли я понимаю, что через каждые 25 секунд коннект рвется и заново инициируется скриптом?
Да, он живет 25 сек., если ничего не пришло, то снова подключаемся и т.д.
У вас в конфиге push_stream_last_received_message_tag и push_stream_last_received_message_time, а в яваскрипте вы все равно хедерами пользуетесь. зачем тогда эти строчки?
А вы уже использовали какую-нибудь версию из ветки 0.4.х? Если да, то как впечатления?
Пока что нет, сейчас используем стабильную 0.3.5.
А вообще 0.4.х очень ждем из-за встроенной поддержки балансера.
Как мне объяснил автор, текущая 0.4.x чуть ли не стабильнее, чем 0.3.5. Также в 0.4.x есть новые приятные плюшки, поэтому мы сразу стали внедрять ее. Чуть попозже проапгрэйдимся до релиза 0.4.0.
Вчера гоняли 0.4.х с помощью jmeter, 10к соединений оно держит без проблем.
Это здорово.
У нас в среднем 70-85К постоянных соединений (subscribers) и параллелить их приходится в ручную (просто раскидываем разные ренжы). Так что 0.4 ждем именно из-за балансинга out of the box.
Sign up to leave a comment.