ПРОЕКТЫ 


  АРХИВ 


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: HTTP Streaming. Возможно?



И не обращая внимания на реализацию: http://developers.sun.com/learning/javaoneonline/2006/coreplatform/TS-1315.pdf

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

Ваш вариант - один клиент - один поток. На FastCGI ничего не выйдет. С
тем же успехом  пишите модуль к апачу.
Результат будет один и тот же.

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

Спасибо, поищу данную книгу (есть в городе магазин в котором его
предлагают... даааа приличный талмут под 1кстраниц). Уже давно есть
желание более детально ознакомиться с моделью установки соединения на
уровни ОСи.
А 1000 мне не нужно.. Сотни хватит.
За FastCGI я взялся в надежде реализовать задуманное в рамках более менее
готовых решений. Всегда считал, что нет смысла изобретать велосипед. Но
видимо придется засеть за изучение С++. Это язык мне пока нравиться больше
всего.


public-mail@xxxxxxxxxx wrote:
Потребление памяти будет немалым, посколько в том варианте который вы
предлагаете придется держать отдельный процесс FastCGI на каждое
открытое
соединение.

"Немалое" понятие относительное. Уж точно меньше на несколько порядков,
чем mod_apache. И почему она будет потреблсять? Данных содержать она
будет
очень мало, т.к.. все будет находиться в разделяемой памяти.. Если бы не
затык с буферизацией в nginx сейчас бы даже мог сказать, столько
ресурсов
ушло бы на это дело.

Ну так в FastCGI в пределах одного процесса имеем несколько тредов
(нитей). Значит если в настройках задать в пределах одного процесса 5
тредов, то один процесс сможет у нас удержать 5 конектов. 20 таких
процессов и уже 100 коннектов. Сейчас на один процесс на тестовой машине
уходит ~10МБ на пятитредовый процесс. Тот же Апач в стандарной
конфигурации требовал 100МБ.






 




Copyright © Lexa Software, 1996-2009.