[Moscow.pm] FastCGI

[Anatoly Sharifulin]

Интересное мнение :)
Давайте устроим онлайн хакатон - сделаем теситрование различных серверных
решений:
 - FastCGI
 - mod_perl2
 - HTTP::Daemon
 - Net::Server
 - Catalyst::Engine
 - POE

Я могу написать на POE, вариантов несколько, в т.ч. и pre-fork есть.
Только нужно опеределиться с прикладной логикой, которую будем тестировать
(желательно, не Hello World тестировать :).
Тестирование следует проводить всех решений на ОДНОМ сервере.
Что важно:
 - производительность (количество запросов в секунду)
 - использование ресурсов (память, CPU, количество процессов)
 - отказоустойчивость
 - расширяемость
и прочее

Давайте определимся и сделаем это.
Т.к. вопрос всех давно интересует, а реального сравнения нет.

27 мая 2008 г. 10:10 пользователь Sergey Skvortsov <skv на protey.ru> написал:

> Anton Yuzhaninov wrote:
> > On 26.05.2008 23:24, Sergey Homenkow wrote:
> >>> Что в мире перла сейчас наиболее правильно использовать для написания
> >>> fastcgi сервисов ?
> >> Предлагаю дискуссию на тему "протокол FastCGI против HTTP".
> >>
> >> Последние два сервиса делал на HTTP::Daemon
>
> Чем больше я смотрю на FastCGI, тем меньше вижу в нём смысла.
>
> Рассмотрим связку nginx + perl-backend/fastcgi.
>
> Что позволяет FastCGI? Ничего интересного.
>
> 1. Frontend парсит входящий запрос и преобразует его в FastCGI
> 2. Backend берет request и что-то с ним делает (зачастую - тупо
> преобразует в HTTP::Request).
> 3. Отдаёт ответ.
>
> Всё то же самое позволяет делать просто HTTP.
>
> Плюсы HTTP:
> - нет overhead'а на преобразование HTTP -> FastCGI -> HTTP
> - легко отлаживать соединения через tcpdump
> - понятный log tracing
> - не надо знать ещё один протокол (сколь бы ни простым он был)
> - текстовые протоколы рулят!
>
> Что могло бы быть интересным плюсом FastCGI?
>
> - authorizer. Nginx этот режим не поддерживает - да особо и не надо.
>
> - filters. Аналогично. Лучше задачу template system на frontend как-то
> другим образом решить (если в такой задаче вообще есть смысл)
>
> - мультиплексирование. Мало FastCGI-managers в принципе это умеют, да и
> мало кто из программирует в расчёте на мультиплексирование.
> Даже если хочется мультиплексирования (а keep-alive backend в nginx пока
> и нет), то лучше это сделать как-то более системно (ну скажем такой
> экзотический вариант: HTTP-over-BEEP).
>
> В общем, FastCGI - это для PHP.
>
> Вывод:
> - важна скорость/изолированность: пишите свой http backend daemon (это
> просто!)
> - важна функциональность: mod_perl2
>
> imho оптимальный вариант из Engine для Catalyst сейчас -
> Catalyst-Engine-HTTP-Prefork (надо только туда добавить поддержку unix
> sockets).
>
> Интересно было бы сравнить memory overhead для Perl-backend'а на:
> - FastCFI
> - HTTP::Daemon / Net::Server
> - mod_perl2
>
> Есть сильное подозрение, что разница не столь уж значительна - даже в
> сравнении с mod_perl2.
>
> > FastCGI позволяет писать логи на фронтенде (stderr можно отправлять на
> фронтенд).
> >
> > В случае HTTP::Daemon надо сомому реализовывать запись логов в файлы и их
> переоткрытие по сигналу для ротации.
>
> Используйте Log::Log4perl - там _всё_ что надо уже есть.
> В т.ч. ротацию по сигналу, watching логов.
>
> --
> Sergey Skvortsov
> mailto: skv на protey.ru
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
> http://mail.pm.org/mailman/listinfo/moscow-pm
>



-- 
С уважением,
Анатолий Шарифулин.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: http://mail.pm.org/pipermail/moscow-pm/attachments/20080527/d354105d/attachment.html