ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[4]: + поправка на мультиплексирование



DM>>> 1) Nginx НЕ передаёт ID соединения бэкенду. Вместо этого бэкенд сам
DM>>> решает,
DM>>> к какой группе (!) относится данный юзер (на основании
DM>>> авторизационной информации
DM>>> и т.п.) и возвращает nginx-у список ГРУПП (или их uid-ов), к
DM>>> которым относится
DM>>> данное соединение. Таблицы соответствий ConnectionID <-> GroupID
DM>>> хранит у
DM>>> себя сам nginx, это не должно быть особо ресурсоёмко. Чистятся
DM>>> таблицы по
DM>>> мере отваливания клиентов.
>> Не просек фишку про группы. Почему это лучше, чем передавать ID
>> соединения, возложив работу с группами на скрипт? Если поддержку групп
>> пихать в nginx, получится, что мы в него уже бизнес-логику
>> заталкиваем, о вредности которой предупреждали большевики :)
>> 
>> Вы не могли бы подробнее объяснить, в каких ситуациях без групп
>> непосредственно в nginx не обойтись? Или когда от них будет огромный
>> выигрыш.

DM> Огромный выигрыш будет, когда в чат придут 10000 человек, и их всех придётся
DM> перечислять при постинге очередного сообщения:) И nginx-у парсить такие 
запросы
DM> -- никакого интереса. Ну пусть не 10000, пусть 100 -- вполне реальная цифра.
DM> Зачем каждый раз пихать в запрос сто лишних хедеров, при том, что их состав
DM> почти не меняется? А с группами мы можем вообще не волноваться, сколько там
DM> народу, кто отвалился, кто подсоединился. Опять же, можно создавать группы
DM> для конкретных юзеров. Эмулировать же группы на бэкенде в случае с ID-ами
DM> соединений довольно сложно -- надо где-то хранить состояния, обновлять их
DM> при подсоединении-отсоединении... А пул коннектов в nginx и так имеется,
DM> разбить его на группы -- совершенно не сложно.

DM> Мне кажется, группы -- это настолько общий паттерн, что его вполне можно
DM> перенести в мультиплексор. На "бизнес-логику" это никак не тянет.

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

Вот если 10 000 - тогда действительно могут проблемы возникнуть. Хотя
я плохо представляю ситуацию, когда надо на ЕДИНСТВЕННОМ канале
столько клиентов держать. Может, потому что живые ленты новостей еще
не изобрели - там вполне возможно. А с другой стороны, можно для этих
целей "мультикаст" сочинить.

В общем, я пока к группам ровно дышу, но они мне и не мешают.




 




Copyright © Lexa Software, 1996-2009.