The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

FastCGI или mod_perl, пример оформления FastCGI скрипта на Perl (perl fastcgi web)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: perl, fastcgi, web,  (найти похожие документы)
From: Николай <http://kiev.pm.org/>; Date: Mon, 16 Dec 2007 14:31:37 +0000 (UTC) Subject: FastCGI или mod_perl, пример оформления FastCGI скрипта на Perl Оригинал: http://kiev.pm.org/?q=node/111 С января 2001 года сфера моей профессиональной деятельности тесно связна с созданием web-сервисов, в основном аналитических. Одной из технологий, используемых в работе, является mod_perl. FastCGI не использовался ни разу. Почему? Как часто отвечают: "по историческим причинам". А вот сейчас решил посмотреть в сторону FastCGI подробней. Специфика нового проекта подразумевает наличие frontend'да, например, nignx. "Нет, проблем", - говорю сам себе: "frontend'ом будет nignx, а backend'ом - Apache". Но не так все просто. В рассылке по nignx, до того как было все разложено по полочкам в различных документациях и заметках, часто задавались вопросы по использованию PHP в режиме FastCGI. То есть люди массово избавлялись от Apache mod_php, переходя не FastCGI. При этом, что в тот момент, не знаю как сейчас, патч php-fpm (http://php-fpm.anight.org/) не был включен в официальные исходники, так что многие пользовалось spawn-fcgi от lighttpd. Что это? Дань моде или нечто большее? Тем не-менее этот процесс подтолкнул меня посмотреть подробней, какие есть у FastCGI преимущества. Да, я знаю, mod_perl и mod_php координально отличаются в области загрузки кода, но будем считать, что php акселераторы работают хорошо и это не является причиной перехода с mod_php на FastCGI. Известно, что процессы Apache с mod_perl очень прожорливы на память. Может с FastCGI ее требуется меньше? Теоретически разница не должна быть слишком большой: ведь под mod_perl можно все используемые модули загрузить до начала создания дочерних процессов. Стоп! Если мне не изменяет память, то mod_php так не может! Наверно это и есть причина перехода с mod_php на FastCGI. Хм, но ведь и spawn-fcgi в этом вопросе не помощник... Тем не-менее с FastCGI решил разобраться до конца. Прописал в конфиге nignx какой порт слушать и занялся perl. Для perl существует три основных модуля FCGI, FCGI::ProcManager и FCGI::Spawn. (о FCGI::Async и других разговор не ведем). Первый является основным, второй - это менеджер процессов. Третий является надстройкой над первым двумя и предназначен для запуска скриптов через require, то есть является в некотором смысле аналогом Apache::PerlRun, поэтому мы его не рассматриваем. Модули FCGI, FCGI::ProcManager являются очень "зрелыми" и все приведенные примеры предназначены для запуска FastCGI из-под "пускалок", а не как самостоятельные, поэтому все примеры слегка модифицируем. Перед основным циклом открываем сокет, который будет слушать nignx: use FCGI; use CGI; my $socket = FCGI::OpenSocket(":9000", 5); my $request = FCGI::Request(\*STDIN, \*STDOUT, \*STDERR, \%ENV, $socket); my $count = 0; while($request->Accept() >= 0) { $count++; print <<TEXT; Content-Type: text/html <h1>hello</h1> $count <hr> TEXT print "$_ = $ENV{$_}<br>\n" foreach sort keys %ENV; print "<hr>\n"; my $query = CGI->new(); print "$_ = ", $query->param($_), "<br>\n" foreach sort $query->param(); } FCGI::CloseSocket($socket); Но это пример имеет большой недостаток: всего лишь один процесс FastCGI. На помощь приходит модуль FCGI::ProcManager, который создает до основного цикла заданное количество потомков, выполняющих всю полезную работу по обработке запроса: use FCGI; use FCGI::ProcManager; use CGI; my $proc_manager = FCGI::ProcManager->new({ n_processes => 10 }); my $socket = FCGI::OpenSocket(":9000", 5); my $request = FCGI::Request(\*STDIN, \*STDOUT, \*STDERR, \%ENV, $socket); $proc_manager->pm_manage(); my $count = 0; while($request->Accept() >= 0) { $count++; print <<TEXT; Content-Type: text/html <h1>hello</h1> $count <hr> TEXT print "$_ = $ENV{$_}<br>\n" foreach sort keys %ENV; print "<hr>\n"; my $query = CGI->new(); print "$_ = ", $query->param($_), "<br>\n" foreach sort $query->param(); } FCGI::CloseSocket($socket); Кстати, если кто знает ответе: в линуксе до сих про плохо с большим количеством прослушивающих один сокет процессов и проходится перед аccept делать монопольную блокировку файла "регулировщика"? Вернемся к основной теме. В примерах использования FCGI::ProcManager используется модуль CGI::Fast, используя которых вышеприведенный вариант можно привести к следующему виду: BEGIN { $ENV{FCGI_SOCKET_PATH} = ":9000"; $ENV{FCGI_LISTEN_QUEUE} = 5; } use CGI::Fast; use FCGI::ProcManager; my $proc_manager = FCGI::ProcManager->new({ n_processes => 10 }); $proc_manager->pm_manage(); my $count = 0; while(my $query = CGI::Fast->new()) { $count++; print <<TEXT; Content-Type: text/html <h1>hello</h1> $count <hr> TEXT print "$_ = $ENV{$_}<br>\n" foreach sort keys %ENV; print "<hr>\n"; print "$_ = ", $query->param($_), "<br>\n" foreach sort $query->param(); } Теперь рассмотрим фрейморки Catalyst и CGI::Application. Для Catalyst создаем новый проект catalyst.pl MyApp и запускаем myapp_fastcgi.pl -listen=localhost:9000 -nproc=10 Все просто. А вот с CGI::Application немного сложней. Модуль CGI::Application::FastCGI, как оказалось, предназначен для работы из-под "пускалки", поэтому используем не его, а непосредственно FCGI::ProcManager. BEGIN { $ENV{FCGI_SOCKET_PATH} = ":9000"; $ENV{FCGI_LISTEN_QUEUE} = 5; } use WebApp; use CGI::Fast; use FCGI::ProcManager; my $proc_manager = FCGI::ProcManager->new({ n_processes => 10 }); $proc_manager->pm_manage(); while(my $query = CGI::Fast->new()) { my $app = WebApp->new(QUERY => $query); $app->run(); } Ну вот, с запуском разобрались, теперь посмотрим на использование памяти в реальных условиях. Как и ожидалось выигрыша по памяти почти нет, разумеется, когда Apache собран без излишеств. Так что за nignx можно смело ставить либо mod_perl, либо FastCGI. Это когда один скрипт. А когда скриптов несколько и они используют множество общих модулей, то выигрыш варианта с mod_perl очевиден. Ну вот пожалуй и все. P.S. Если я где-то ошибся в рассуждения, просьба поправить.

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ RSS ]
  • 1, McFist (?), 23:05, 13/01/2008 [ответить]  
  • +/
    <i>То есть люди массово избавлялись от Apache mod_php... Что  это?  Дань  моде  или  нечто  большее?</i>

    Знаете отчего? Стас Бекман бросил проект, человек которому он его препоручил, philippe chiasson, тоже имеет его глубоко в виду, а люди которые в dev боятся как коммитить баги, так и развивать проект, абы чего не вышло. Поэтому mod_perl медленно но уверенно дохнет.

     
  • 2, Edward (??), 11:35, 05/09/2012 [ответить]  
  • +/
    Nu neznau-neznau!
     
  • 3, Edward (??), 11:35, 05/09/2012 [ответить]  
  • +/
    Nu neznau!
     
  • 4, Edward (??), 12:11, 23/04/2018 [ответить]  
  • +/
    Nu neznau!
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру