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

[public-mail at alekciy.ru]

> По своему опыту скажу что это худший вариант пуша. Ограничение наступает
> очень быстро.
> Что либо около 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МБ.