Xpoint
   [напомнить пароль]

Простая но функциональная организация FastCGI на Perl

Метки: [без меток]
2011-04-18 15:29:16 [обр] Thirteensmay(4/157)[досье]

Необходимо организовать FastCGI на Perl, удовлетворяя следующие условия:

  1. Должно работать без изменений на Linux и Windows
  2. Должно логировать ошибки в скриптах
  3. Должно позволять управлять пулом процессов, желательно автоперезапуск по таймауту и после изменения скрипта на диске
  4. Желательно готовое решение или минимум ручного кодирования
  5. Желательно не модуль апача а свой FastCGI сервер с менеджером процессов

Пробовал mod_fastcgi - модуль апача, не логирует ошибки. mod_fcgid - модуль апача, не смог заставить работать под Windows. Рассматриваю вариант http://m-ivanov.livejournal.com/4436.html - есть сомнения что просто так заработает под Win и пр, в правильном ли я направлении двигаюсь ? т.е. готового нет, придется разбираться и ручного кодирования сервиса не избежать ?

спустя 23 минуты [обр] Евгений Седов aka KPbIC(0/176)[досье]
mod_fcgid свежее, активней чем mod_fastcgi и с недавних пор разрабатывается под эгидой Apache Foundation. Если нужен минимум ручного кодирования при максимуме функционала и стабильности, я бы сначала испытал его.
спустя 34 минуты [обр] Thirteensmay(4/157)[досье]

Ну я честно говоря с него и начал, но под винду не работает, официальная виндовая сошка

#!/usr/bin/perl
use CGI::Fast;

while (new CGI::Fast)
{
  print "Content-type: text/plain;\n\n";
  print "Ok";
}

Пришлось приписать .exe к шибангу, иначе совсем не запускается, после чего валит ошибку (OS 109)The pipe has been ended. : mod_fcgid : get overlap result error поиск показывает что проблема не у меня одного но решения нет ;(

Да и вообще, привязка к апачу получается, нехорошо ;) Хотелось бы еще чтото вроде nginx, вроде как и нагрузку лучше держит и лицензия и т.п.

спустя 32 минуты [обр] Евгений Седов aka KPbIC(0/176)[досье]

В этой конструкции могут фигурировать 3 протокола:

  • протокол, по которому клиент (браузер) стучится на веб-сервер (фронтэнд, может быть, nginx) — очевидно, HTTP;
  • протокол, по которому фронтэнд разговаривает с бэкендом (HTTP или FastCGI);
  • если в предыдущем пункте HTTP, то FastCGI, по которому бэкенд общается со скриптом, и тогда, FastCGI можно заменить на mod_perl в случае, если бэкендом выступает Apache.

Вам куда и для чего понадобился FastCGI и где должна быть кросс-платформенность?

спустя 2 часа 2 минуты [обр] Thirteensmay(4/157)[досье]

Понадобился вообще, судя по тестам которые я провел в моих условиях работает существенно быстрее, поэтому рассматриваю вариант полного перехода на эту технологию во всех своих проектах. Я разрабатываю web-приложения которые генерят много мелких XMLHttpRequest'ов, расходы на обработку непосредственно данных на сервере (запросы к БД и пр.) часто невелики, сравнимы а иногда и меньше накладных расходов CGI, как то запуск каждый раз процесса, подключение модулей, подключение к базе, поэтому есть возможность выигрыша. Разработка идет под Windows, результат же выкладывается как правило под Linux, поэтому нужна максимальная кроссплатформенность, чтобы меньше заморочек, по крайней мере с CGI это получается, вплоть до идентичных версий ПО и конфигов.

В моем случае насколько я себе это представляю фронтендом должен быть легкий HTTP сервер, с минимальными накладными расходами на поддержку соединений, потому что их много, отдающий статику и перенаправляющий запросы к динамике посредствам FastCGI на отдельный FastCGI сервер, который в свою очередь будет заниматься только их обработкой. В качестве фронтенда Apache насколько я понимаю не лучший выбор, в качестве бэкенда вообще наверное подошел бы, но в данном случае по идее не вариант т.к. с фронтенда уже идет FastCGI а не HTTP, впрочем это вопрос всего лишь конфигурации фронтенда. В конечном счете я вполне допускаю вариант Apache как бэкенд, единственное что несколько смущает так это его жирность, но это похоже мелочи.

Вариант mod_perl не рассматриваю, он менее очевиден и сильнее привязывает.

спустя 24 минуты [обр] Евгений Седов aka KPbIC(0/176)[досье]
сообщение промодерировано

Говорю про Apache только в качестве бэкенда. Во-первых, жирок с него можно стряхнуть при сборке. Во-вторых, этот жир бывает полезен: удобные конфиги, логи, навороченный procmanager в случае с FastCGI. И в-третьих, учтите, что так как на FastCGI время обработки одного запроса сокращается на порядки, то и нет необоходимости запускать так много сущностей апача, как в случае с CGI, соответственно и расход памяти меньше.

Про совместимость с Windows для разработки... мне как-то даже неудобно предлагать вам очевидное решение... взять и выкинуть.

спустя 1 час 27 минут [обр] Thirteensmay(4/157)[досье]

С "выкинуть" проблемы, во первых привычка, во вторых в перспективе намечаются серверы под виндой. Web интерфейс там будет одним из модулей большой системы, основные компоненты которой виндовые, потому что во первых смежники, во вторых заказчики. Такие серверы проще обслуживать в мухосрансках где весь обслуживающий персонал - мальчик лаборант, у него от юниксов затмение может случиться.

И дело какраз в том что этот навороченный procmanager под виндой не фунциклирует. Конечно работает mod_fastcgi, но во первых не пишет ошибок скриптов, а во вторых не первой он свежести, на такое не завязываются. Короче попробую пока поковырять procmanager на перл, с виду все просто, может легко заработает, ну а если нет то бум думать дальше.

спустя 3 часа 47 минут [обр] Евгений Седов aka KPbIC(0/176)[досье]
сообщение промодерировано

Thirteensmay[досье]

Привычка — не аргумент. Уже где-где, а в Linux'е недостатка средств разработки нет, что-нибудь по душе обязательно подберете. Web-интерфейс можно вынести в отдельный модуль на отдельную машину и связать с Системой удобным протоколом. Тем более, что это понадобится всего один раз, а как правило результат у вас выкладывается под Linux.

По какому протоколу общаются фронт- с бэкэндом для вас сейчас значения не имеет. В Апаче под Linux все написано и все работает как вам надо, трудозатрат для вас — ноль. Мне кажется, есть смысл начать с простого, а когда (и если) появится нужда в более тонких конструкциях, обратиться к ним. Тогда вы уже будете ясно ориентироваться в том, что и зачем вы используете, и будете представлять как это реализовано не самыми плохими программистами в Apache. Другими словами, я предлагаю подход "от простого к сложному".

спустя 11 минут [обр] Thirteensmay(4/157)[досье]
Это все конечно понятно, но Windows все равно нужен, это сейчас у меня проект который выкладывается под Linux, а в перспективе как я сказал вылезает винда, и никто там отдельной машинки для моего модуля не даст.
спустя 17 часов [обр] Thirteensmay(4/157)[досье]
FCGI::ProcManager под виндой падает с ошибкой "Your vendor has not defined POSIX macro SA_RESTART" ;(
спустя 6 минут [обр] Thirteensmay(4/157)[досье]
сообщение промодерировано
Я вот не понимаю зачем поставлять модули и пакеты которые годами не работают, багрепорты зафиксированы, что за фигня ?
Powered by POEM™ Engine Copyright © 2002-2005