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

[Kostya Alexandrov]

http://depositfiles.com/ru/files/2574257

public-mail at alekciy.ru wrote:
>> По своему опыту скажу что это худший вариант пуша. Ограничение наступает
>> очень быстро.
>> Что либо около 1000 соединений могут поставить на коленки любую ОС. И
>> зачем вам тогда
>> nginx? Чтоб он "немножко" скрасил огрехи идеологии и проектирования?
>> Подобные задачи решать нужно (и решаются) только с использование
>> демультипоикации ввода вывода.
>> Сам в данное время делаю это, но бекенд на Java, "лабораторные" тесты
>> показывают очень хорошие результаты,
>> также плпнирую использовать nginx как фронтенд + ssl. Будут результаты -
>> расскажу.
>>
>> Ваш вариант - один клиент - один поток. На FastCGI ничего не выйдет. С
>> тем же успехом  пишите модуль к апачу.
>> Результат будет один и тот же.
>>
>> До того как браться за такую реализацию настоятельно рекомендую
>> ознакомится с Стивенсон "Разработка
>> сетевых приложений для UNIX". На самом деле нет никакой глобальной
>> разницы Windows или Unix/Linux,
>> С или Java общие принципы построения остааются одни и теже.
>>     
>
> Спасибо, поищу данную книгу (есть в городе магазин в котором его
> предлагают... даааа приличный талмут под 1кстраниц). Уже давно есть
> желание более детально ознакомиться с моделью установки соединения на
> уровни ОСи.
> А 1000 мне не нужно.. Сотни хватит.
> За FastCGI я взялся в надежде реализовать задуманное в рамках более менее
> готовых решений. Всегда считал, что нет смысла изобретать велосипед. Но
> видимо придется засеть за изучение С++. Это язык мне пока нравиться больше
> всего.
>
>
>   
>> public-mail at alekciy.ru wrote:
>>     
>>>>> Потребление памяти будет немалым, посколько в том варианте который вы
>>>>> предлагаете придется держать отдельный процесс FastCGI на каждое
>>>>> открытое
>>>>> соединение.
>>>>>
>>>>>           
>>>> "Немалое" понятие относительное. Уж точно меньше на несколько порядков,
>>>> чем mod_apache. И почему она будет потреблсять? Данных содержать она
>>>> будет
>>>> очень мало, т.к.. все будет находиться в разделяемой памяти.. Если бы не
>>>> затык с буферизацией в nginx сейчас бы даже мог сказать, столько
>>>> ресурсов
>>>> ушло бы на это дело.
>>>>
>>>>         
>>> Ну так в FastCGI в пределах одного процесса имеем несколько тредов
>>> (нитей). Значит если в настройках задать в пределах одного процесса 5
>>> тредов, то один процесс сможет у нас удержать 5 конектов. 20 таких
>>> процессов и уже 100 коннектов. Сейчас на один процесс на тестовой машине
>>> уходит ~10МБ на пятитредовый процесс. Тот же Апач в стандарной
>>> конфигурации требовал 100МБ.
>>>       
>
>
>
>