Re: HTTP Streaming. Возможно?

[Kostya Alexandrov <koticka@xxxxxxx>]

По своему опыту скажу что это худший вариант пуша. Ограничение наступает 
очень быстро.
Что либо около 1000 соединений могут поставить на коленки любую ОС. И 
зачем вам тогда
nginx? Чтоб он "немножко" скрасил огрехи идеологии и проектирования?
Подобные задачи решать нужно (и решаются) только с использование 
демультипоикации ввода вывода.
Сам в данное время делаю это, но бекенд на Java, "лабораторные" тесты 
показывают очень хорошие результаты,
также плпнирую использовать nginx как фронтенд + ssl. Будут результаты - 
расскажу.
Ваш вариант - один клиент - один поток. На FastCGI ничего не выйдет. С 
тем же успехом  пишите модуль к апачу.
Результат будет один и тот же.

До того как браться за такую реализацию настоятельно рекомендую 
ознакомится с Стивенсон "Разработка
сетевых приложений для UNIX". На самом деле нет никакой глобальной 
разницы Windows или Unix/Linux,
С или Java общие принципы построения остааются одни и теже.

public-mail@xxxxxxxxxx wrote:
> > > Потребление памяти будет немалым, посколько в том варианте который вы
> > > предлагаете придется держать отдельный процесс FastCGI на каждое
> > > открытое
> > > соединение.
> > >       
> > "Немалое" понятие относительное. Уж точно меньше на несколько порядков,
> > чем mod_apache. И почему она будет потреблсять? Данных содержать она будет
> > очень мало, т.к. все будет находиться в разделяемой памяти.. Если бы не
> > затык с буферизацией в nginx сейчас бы даже мог сказать, столько ресурсов
> > ушло бы на это дело.
> >     
> Ну так в FastCGI в пределах одного процесса имеем несколько тредов
> (нитей). Значит если в настройках задать в пределах одного процесса 5
> тредов, то один процесс сможет у нас удержать 5 конектов. 20 таких
> процессов и уже 100 коннектов. Сейчас на один процесс на тестовой машине
> уходит ~10МБ на пятитредовый процесс. Тот же Апач в стандарной
> конфигурации требовал 100МБ.
>
>
>
>