FastCGI, mod_perl и прочие

С января 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. Если я где-то ошибся в рассуждения, просьба поправить.

Автор: Николай

Сайт: http://kiev.pm.org/