Mod perl в IkonBoard 302

[Vladn]

в файле ikonboard.cgi есть такие строчки:

Код: [Выделить]

require Boardinfo;
...
require Lib::FUNC;
require Sessions;
require iDatabase::SQL;
То есть там полно require, в том числе и через eval. Как будет себя вести mod_perl, втретив require? Запустит ли он компилятор или найдет скомпилированный код для подключаемого модуля? И вообще, переваривает ли mod_perl require? Ведь на странице http://www.hosting.zenon.net/documentation/v-www/0026.html написано:

При миграции на mod_perl необходимо учитывать, что переносимый скрипт должен соответствовать некоторым требованиям. В скрипте не должны использоваться:
директива require, так как Вы не сможете получить доступ к переменным и процедурам требуемого модуля,
директивы _DATA_ и _END_,
функция exit(). Вместо нее используется Apache::exit()

Объясните мне, пожалуйста. Я переделываю гостевушки под mod_perl и у меня полно require.

[ondr]

Документация извращена до безобразия! Вероятнее всего написанна с учетом пожеланий хостера.

Зайди на родную страничку http://perl.apache.org или вот очень здоровский сайт http://www.take23.org.

В основной массе изменения касаются стартового скрипта. Если использовать PerlRun вместо Registry, их еще меньше. Пользуйся require как и пользовался раньше. Директивы __DATA__, __END_ и пр. нельзя использовать, опять же, лишь в стартовом скрипте.

Советы:
- Если хочешь перевести свои cgi\'шные скрипы под mod_perl используй PerlRun, Отличий немного, вот навскидку: больше не существует стартового скипра под именем main, имя у него теперь побольше(сильно больше) , про процедуру END{ } забудь, модули раз предкомпилируются и далее не перегружаюся, даже при изменении (эта проблема легко решается, чти маны). Вроде все если ничего не забыл.
- Если решишься на Registry осторожнее с памятью, perl назад ничего не отдает Да и переменные ведут себя несколько иначе
- Решаться на Registry большого смысла нет, если у тебя стартовый скрипт небольшого размера.
- Можно поступить следующим образом, все помещаешь в модули, а стартовый скрипт выгрядит примерно так:
#!/usr/bin/perl
require Something;
--------
ну как из примера понятно, стартовый скипт целиком перекочевал в модуль Something.pm
Данная конструкция работает и под mod_cgi и под mod_perl(в любом исполнении)

[Vladn]

Спасибо за столь обширный ответ. Я только начал знакомство с mod_perl, поэтому и возникют вопросы. Сейчас читаю книжку http://perl.apache.org/docs/1.0/guide/guide.pdf.

Пользуйся require как и пользовался раньше.

Я думаю (может быть неправильно), что если я буду пользоваться require в том же объеме, что и пользовался ранее, то все преимущества mod_perl сойдут на "нет". Ведь тогда апачу придестся загружать компилятор, компилировать текст, который я подключил по require. Как я понимаю, основное преимущество mod_perl заключается именно в том, что удается избежать стадии компиляции.

Я пробовал использовать require в mod_perl - получается какая-то ерунда. Во первых, что-то произошло с указателем на текущую дерикторию: \'./\' и \'../\' теперь не работают, приходится указывать абсолютный путь. Причем require \'module.cgi\' еще проходит, а use module уже нет (с учетом, что module.cgi и module.pm находятся в той же дериктории). Приходится говорить use lib (\'текущая директория\'). Потом написал простенький скрипт с require:

Код: [Выделить]

файл mod2.cgi
print "Content-type: text/plain\\n\\nBegin\\n";
require \'mmm.cgi\';

файл mmm.cgi
print "AAAAAAAAAAAAAAAAAAAAAAAA";
Выдается только Begin. В других экспериментах при первом обращении к скрипту было видно, что необходимый файл подключается, а при повторных обращениях файл уже не подключался.
Может быть, проблема в том, что я подключаю чистый текст, а не модуль.

Если хочешь перевести свои cgi\'шные скрипы под mod_perl используй PerlRun

Насколько я понимаю, PerlRun не такой быстрый как Registry. В указанной книжке написано: "Apache::PerlRun is usually useful in the transition period, while the scripts are being cleaned up to run properly under Apache::Registry. Though it gives you a significant speedup over mod_cgi, it\'s still not as fast as Apache::Registry and mod_perl handlers."
Как говорится в одном известном мультике "Лучше день потерять, потом за пять минуть долететь". Поэтому я лучше помучаюсь с Registry, зато потом скрипты будут летать.

[ondr]

1. Тебе во первых нужно научится пользоваться require и use и, что важнее понять как они работают.

require \'blabla.cgi\' - больше не пользуйся этим.
в место этого позуйся класическим представлением модуля

К примеру выберем директорию /PM относительно корня сайта, куда будем класть все модули

blablabla.pm - обзываем все модули с расширением .pm
----
package PM::blablabla; # Данная директива выделяет нам чистую таблицу переменных, это гарантирут, что переменные у нас никогда не пересекуться. PM::blablabla - это внутреннее представление perl\'а о путе до модуля, соответствует PM/blablabla.pm в реале.

...
...
...


1;  # Последняя строка должна выглядеть так, ибо require хочет, чтоб модуль всегда возвращал истинный результат

---

Теперь о подключении модуля:
-----
# Perl ищет модули в путях, записанных в массиве @INC, поправим его

BEGIN { unshift @INC, $ENV{DOCUMENT_ROOT} }
# use lib $ENV{DOCUMENT_ROOT} - тоже самое

# теперь  чтобы подключить его нужно воспользоваться require или use
# use PM::blablabla @params - это примерно тоже самое что и BEGIN { require PM::blablabla; import PM::blablabla @params }

use PM::blablabla;

---
Почитай документацию по этим директивам + perldoc Exporter;

2.

что если я буду пользоваться require в том же объеме, что и пользовался ранее, то все преимущества mod_perl сойдут на "нет"

Это не так.

3. Registry предкомпилирует все, PerlRun все кроме стартового скрипта и обнуляет переменные при выходе. На практике между PerlRun и Registry разница почти незаметна при небольшом стартовом скрипте. Но проблем существенно меньше. Плюсы минусы я описал. Решать тебе.

зы: Преимущество mod_perl еще и в том, что с ним не порождается новый процесс каждый раз когда запускается скрипт как при mod_cgi

[ondr]

В догонку:

Под mod_perl предпочтительнее пользоваться PerlSetEnv PERL5LIB в конфиге апача вместо use lib. Узнать что скрипт запущен под mod_perl можно по значению $ENV{MOD_PERL}



ps: И я немного ошибся в первом сообщении. Так как я описал, скрипт выполниться лишь 1 раз. Правильнее будет так:

#!/usr/bin/perl
require Something;

Something::process(); # Где process() - функция в которую помещен весь код (все кроме подключения других модулей). Предкомпилируется она один раз, но пользоваться можно сколько угодно раз.

[Vladn]

Спасибо за ликбез.
Моя проблема в том, что я изучал перл не по книжкам, а по произведениям искусства российских программеров. А там были сплошные require. Причем подключались не модули, а голый текст. Вот теперь переучиваюсь.
Выбор между Registry и PerlRun я сделаю после прочтения руководства по mod_perl.


Я тут слежу за своим конкурентом borda.ru. Он раньше писал, что перешел на mod_perl. Теперь хвалится тем, что его скрипты используют FastCGI. Нельзя ли в двух словах рассказать о том, чем принципиально отличается FastCGI от mod_perl и как соотносятся их скоростные характеристики?

[ondr]

Моя проблема в том, что я изучал перл не по книжкам, а по произведениям искусства российских программеров.

Попробуй CPAN\'овские произведения. Многие(но не все) очень интересно написаны и есть чему поучиться.


FastCGI не пользуюсь и не пользовался, когда то читал, про это, но уже не помню что. Жди, может кто нибудь и ответит.

[NeoNox]

Я его пользую. Смысл FastCGI заключается в том что скрипт стартует как сервис и поднимается в память. Компилится только один раз при запуске Apache. Работать с ним очень просто но и неприятностей с ним тоже есть немало. Насчет скоростных характеристик - гугль тебе поможет.
ЗЫ. Я сейчас более склоняюсь к использованию mod_perl, но это субьективно.

[Vladn]

А насколько активно поддерживают хостинг-провайдеры технологии mod_perl и FastCGI и какой из них отдают большее предпочтение?

[ondr]

Под mod_perl нужен не менее чем виртуальный выделенный(полувыделенный) сервер.

[NeoNox]

ondr под fastcgi тоже самое. А точнее доступ к конфигам апача.