Помогите понять в чем преимущество мультиплексора dklab_multiplexor перед обычным fast_cgi который висит в памяти.
Все равно ведь на клиенте мы через javascript посылаем запрос толи к мультиплексору толи к фаст цги демону.
Я не могу понять в чем выигрышь.

frenkys, dklab верно сообщает, что поддержание соединения с сервером для получения новых данных более эффективно, чем его периодический опрос. dklab_multiplexor используется для обработки большого количества таких соединений. Посчитайте, сколько потребуется памяти для обработки такого количества соединений при помощи fast_cgi и поймете, в чем выигрыш.

P.S. еще обращаю внимание, что miltiplexor используется только для отдачи данных клиентам, запросы клиентов должны идти в обход miltiplexor'а.

Это сообщение отредактировал(а) ginnie - 11.11.2009, 15:49

Ну ведь постоянный коннект :
На стороне клиента  через JS это и есть опрос по таймауту.



Мультиплексор же знает кому что отдавать значит он как минимум принимает параметр id 




Тоесть получаеться вся разница в архитектуре fast_cgi - изза  того что он не libevent ?

Добавлено через 4 минуты и 29 секунд
Вот например я проверяю количество новых сообщений которое пришло пользователю с помощью js раз в 1 минуту   (джс обращаеться к демону и берет из мемкеша данные)
использование мультиплексора для этих целей даст выигрышь?

Смотрю гмаил -там количество сообщений тоже проверяется раз 100ms

frenkys, алгоритм работы такой: устанавливаем с сервером соединение для получения данных (информации о письмах) и не разрываем его. Если на сервер пришло письмо, то в установленном соединении клиенту приходят новые данные, которые он обрабатывает. Соединение не разрывается. Пришло еще одно письмо, и данные снова передаются клиенту. Никакие данные от клиента в этом соединении на сервер не передаются. Если надо что-то передать, делается отдельное обычное (недолгоживущее) соединение.
Такой алгоритм работы удобен в основном для чатов.

P.S. libevent - всего лишь библиотека, реализующая событийную машину (я лично обычно использую libev) и никак не связана с обсуждаемым вопросом (т.к. событийная машина используется также и в fast_cgi).

Это сообщение отредактировал(а) ginnie - 11.11.2009, 16:13

Спасибки, до меня начинает по-тихонечку доходить =)

ginnie, а чем mod_perl не подойдет?

я где-то видел что подобное как event встроенное в апаче, т.е. если будет много соединений, то очень много памяти жраться не будет только из-за соединения...

еще kevent есть в unix  (в linux по другому называется) с помощью события ядра можно построить высокопроизводительный веб-сервер http://search.cpan.org/~msergeant/IO-KQueue-0.32/KQueue.pm  http://www.opennet.ru/base/dev/kevent_freebsd.txt.html но это для очень и очень нагруженных проектов, а не таких где....

еще fast_cgi жрет жестко память, если ее мало на сервер, лучше не использовать fast_cgi

Это сообщение отредактировал(а) gcc - 12.11.2009, 00:03

gcc, задача такая: соединится с сервером, поддерживая соединения получать от сервера новые данные (сообщения чата).
Предложи решение с использованием mod_perl.

ginnie, точно не скажу, но примерно как думаю:
(я имел ввиду fcgi vs mod_perl)

главное преимущество mod_perl то что он кэширует код во время выполнения в режиме Apache::Runtime, правильно?

в документации я увидел что многие веб-сервера используют данные технологии select/kevent/epoll, т.е. открытие нового соединения возможно скорее всего не будет сильно затруднительно?
Ускоряем свой HTTP-сервер и accept-фильтры

в документации Catalyst написано что mod_perl будет быстрее

еще писали портал на котором 10 млн хостов,в котром был Catalyst+MooseX+mod-perl там блы чат и очень много всего (не знаю как все работало, но писали что под Catalyst+mod_perl2)

например, может нужно выбирать fcgi или mod_perl в замисимости от контента? например, большой хостинговый сервер картинок отдает картинки через fcgi 

====
а Server Push говорят как-то можно реализовать в Apache MPM event для apache 2.2 mod_perl 
http://javascript.ru/ajax/server-push/over...nnoe-soedinenie
http://forums.devx.com/showthread.php?t=163336

Это сообщение отредактировал(а) gcc - 12.11.2009, 18:31

Этот мультиплексор и factcgi служат совершенно разным целям. 

Fastcgi - это протокол общения между веб-сервером и сервером приложений. Его нельзя выставить "наружу", обязательно нужен веб-сервер. Более того, веб-сервер с сервером приложений могут общаться и по http, и (в обобщённом смысле) через mod_perl, или через что-то своё (что делает dklab_multiplexor, если я правильно помню).

dklab_multiplexor в этой цепочке является заменой веб-серверу, позволяя эффективно общаться с клиентами с определённой задачей. Вам все равно нужен какой-то сервер приложений, который будет поставлять данные.

спасибо, разобрался