Использование mod_perl

Прислал: Бурмистров Андрей [ 17.01.2003 @ 14:12 ]
Раздел:: [ Статьи по Perl ]

( http://webscript.ru///perl.apache.org/ )

Mod_perl — это С модуль Apache, реализующий Perl интерпретатор + набор Perl модулей, предоставляющих следующие интересные возможности:

1. Кэширование откомпилированых cgi скриптов (Apache::Registry.pm)

2. Perl интерфейс к C API Apache

Большинство разработчиков используют mod_perl чтобы увеличить производительность своих скриптов — Apache не запускает новый процесс при каждом запросе к script.pl, т.к. имеет теперь свой Perl интерпретатор, и не компилирует script.pl при каждом запросе, т.к. Apache::Registry.pm хранит ваши откомпилированые скрипты в кэше. Perl интерфейс к C API Apache используется разработчиками не так часто.

Как это выглядит — типичное использование mod_perl.

Мы скомпилировали Apache с поддержкой mod_perl, у нас есть script.pl:

#!/usr/bin/perl
use strict;
use CGI qw(:cgi);
print header (), ’Hi, people!’;

и мы хотим, чтобы скрипт выполнялся интерпретатором mod_perl и кэшировался. Для этого мы изменяем http2d.conf:

# Это мы закомментируем
#### ScriptAlias /cgi-bin/ «/home/my-project.ru/cgi-bin/»

# А это добавим
PerlModule Apache::Registry
<Location /cgi-bin>
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
</Location>

Перезапустим Apache и убедимся, что всё работает.

Конфигурирование mod_perl.

Разберёмся с тем, что мы написали в http2d.conf.
Mod_perl определяет Apache handler ( http://webscript.ru///http2d.apache.org/docs/handler.html ) с именем "perl-script". Следующая запись:

<Location /cgi-bin>
SetHandler perl-script
</Location>

означает, что запросы к /cgi-bin будет обрабатывать код mod_perl.
Mod_perl определяет также несколько директив:

PerlModule Some::Module Other::Module

— директива загружает указаные Perl модули. Скрипты, выполняемые под mod_perl, могут их использовать, не включая функцией use(). С точки зрения скрипта, использование PerlModule отличается от use() тем, что в скрипт не импортируются имена модуля. Модуль, загруженый PerlModule, может также использоваться как обработчик какой-либо фазы обработки запроса, см. ниже.

Perl*Handler Some::Module

— Apache обрабатывает запрос в несколько фаз — (Post-Read-Request, URI Translation, Header Parsing, Access Control, Authentication, Authorization, MIME type checking, FixUp, Response(!), Logging, Cleanup). Директива Perl*Handler регестрирует модуль-обработчик для какой-либо из этих фаз. Наиболее часто используется директива PerlHandler, устанавливающая обработчик для фазы Response. Остальные Perl*Handler директивы (PerlPostReadRequestHandler, PerlTransHandler, PerlHeaderParserHandler, PerlAccessHandler, PerlAuthenHandler, …) используются реже.

В нашем http2d.conf мы указали Apache::Registry.pm как обработчик фазы Response. Когда мы запрашиваем script.pl у сервера, Apache::Registry.pm берёт откомпилированую версию скрипта из своего кэша и запускает. Apache::Registry.pm отслеживает изменения script.pl на диске и при необходимости перекомпилирует его. Однако изменения в модулях, включаемых script.pl не отслеживаются — это долго. Так что если вы изменили какой-либо из своих модулей, перезапустите сервер.

Вы, разумеется, не обязаны использовать Apache::Registry.pm, как делают большинство разработчиков. Напишите ради интереса свой обработчик фазы Response:

package MyOwnResponseGenerator;
use strict;
use Apache::Constants qw(:common);

sub handler {
print «Content-type: text/html\n\n»;
print «Hi people! enjoy this response!»;
return OK; # We must return a status to mod_perl
}
1;

MyOwnResponseGenerator.pm положим там, где мod_perl сможет его найти (perl -e ’print join "\n"e;, @INC’). Отредактируем http2d.conf:

PerlModule MyOwnResponseGenerator
<Location /somelocation>
SetHandler perl-script
PerlHandler MyOwnResponseGenerator
PerlSendHeader On
</Location>

Перезапустим Apache, наберём //my-project.ru/somelocation. Работает!
Подробно о конфигурировании mod_perl:
//perl.apache.org/docs/1.0/guide/config.html

Особенности работы скриптов под Apache::Registry

Две главные особенности работы кэшируемых скриптов, способные испортить много нервов разработчику, если он о них не знает:

1. Глобальные переменные скрипта сохраняют свои значения между запросами:

#!/usr/bin/perl
use strict;
use CGI qw(:cgi);
use vars qw($i);
print header (), ++$i;

запросим этот скрипт несколько раз подряд и получим: 1 2 3 4 5 …
без Apache::Registry картина была бы такой, разумеется: 1 1 1 1 1 …
Не удивляйтесь, если открыв новое окошко IE и повторив процедуру вы снова получите: 1 2 3 4 5 … вместо 6 7 8 9 10 … . Как правило на сервере работают несколько дочерних процессов http2d, каждый из них имеет свою копию вашего скрипта и соответственно свою копию $i.
Команда http2d -x запустит сервер с одним дочерним процессом — удобно для отладки.
Ниже следует пример того, как писать НЕ НАДО:

#!/usr/bin/perl
use CGI qw(:cgi);
use MySecurity qw(:check_user);
use vars qw($allow);

$allow = 1 if check_user (param(’login’), param(’password’));
print header ();
print (($allow) ? ’Some secret data’ : ’Cool hacker? Go away!’);

достаточно одному пользователю указать верные login-password, и все остальные смогут заходить просто так :).

2. Определённые в вашем скрипте функции становятся вложенными во внешнюю функцию. Вот во что Apache::Registry превращает script1.pl:

package Apache::ROOT::perl::script1_2epl;
use Apache qw(exit);
sub handler {
BEGIN { $^W = 1; };
$^W = 1;

### Original begin of script1.pl
use strict;
use CGI qw(:cgi);

my $var = ’a’;
sub show_var { "Var was $var and now is " . ++$var }
print header(), show_var ();
### Original end of script1.pl
}

наша show_var() оказалась определённой внутри handler(), т.е. вложеной. Чем нам это грозит? show_var() не может теперь корректно работать с внешними my() переменными, в нашем случае с my $var. Запустив скрипт несколько раз получим: Var was a and now is b, Var was b and now is c, Var was c and now is d и т.д.
Функция show_var() ’видит’ тот экземпляр my $var, который она ’видела’ при первом выполнении handler().
Подробно эта проблема описана здесь: Scoped Variable in NestedSubroutines. Нас же интересуют её возможные решения:
1. определять функции не в скрипте, а в модуле. Код ваших модулей не обарачивается ни в какие функции, и данная проблема не возникнет.
2. или просто не обращатся из функций к внешним my() переменным.

Предположим, вы пересадили свои скрипты на mod_perl, они некорректно работают из кэша из-за описаных выше проблем, и вам лень их адаптировать. Используйте Apache::PerlRun вместо Apache::Registry. Скрипты не будут кэшироваться, однако по прежнему будут выполняться встроеным Perl интерпретатором.

Подробно о работе скриптов под mod_perl:
//perl.apache.org/docs/1.0/guide/porting.html

Производительность

Оценим ради интереса выигрыш в производительности, который даёт mod_perl:
1. time lwp-request //my-project.ru/cgi-bin/script.pl — запустим несколько раз и оценим среднее время выполнения lwp-request. Наш script.pl здесь работает под Apache::Registry.
2. time lwp-request //my-project.ru/cgi-bin/script.pl — сделаем то же самое, но script.pl работает без mod_perl.
3. time lwp-request //my-project.ru/little_page.html — так мы оценим время, которое в предидущих двух случаях тратилось на компиляцию lwp-request (ибо он на Perl), на передачу запроса и ответа по сети и т.д. вообщем на всё, не касающееся script.pl.

На моём 300Celeron результаты следующие: 774, 1039, 768 миллисекунд соответственно. Т.е. под mod_perl скрипт выполнился за 6мс (774–768), без mod_perl — за 71мс (1039–768). В 12 раз возросла прозводительность, однако! Для реальных скриптов эта цифра будет меньше, конечно.

Пора закругляться

Где взять: //perl.apache.org/dist/mod_perl-1.0-current.tar.gz
Описание Perl модулей, поставляемые с mod_perl: //perl.apache.org/docs/1.0/api/index.html
Документация: //perl.apache.org/docs/1.0/index.html
Кто использует: //slashdot.org/; //search.cpan.org/; //www.wired.com/; More…