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:
і ми хочемо, щоб скрипт виконувався інтерпретатором mod_perl і кешувати. Для цього ми змінюємо httpd.conf:
Перезапустити Apache і переконаємося, що все працює.
Конфігурація mod_perl.
Розберемося з тим, що ми написали в httpd.conf.
Mod_perl визначає Apache handler з ім'ям "perl-script". Наступний запис: означає, що запити до / cgi-bin буде обробляти код mod_perl.
Mod_perl визначає також кілька директив: - директива завантажує вказані Perl модулі. Скрипти, що виконуються під mod_perl, можуть їх використовувати, не вмикаючи функцією use (). З точки зору скрипта, використання PerlModule відрізняється від use () тим, що в скрипт не імпортуються імена модуля. Модуль, завантажених PerlModule, може також використовуватися як обробник будь-якої фази обробки запиту, див. Нижче. - 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, ...) використовуються рідше.
У нашому httpd.conf ми вказали Apache :: Registry.pm як обробник фази Response. Коли ми запитуємо script.pl у сервера, Apache :: Registry.pm бере откомпілірованую версію скрипта зі свого кеша і запускає. Apache :: Registry.pm відстежує зміни script.pl на диску і при необхідності перекомпілюються його. Однак зміни в модулях, що включаються script.pl не відслідковуються - це довго. Так що якщо ви змінили будь-якої зі своїх модулів, перезапустіть сервер.
Особливості роботи скриптів під Apache :: Registry
Дві головні особливості роботи Кешована скриптів, здатні зіпсувати багато нервів розробнику, якщо він про них не знає:
1. Глобальні змінні скрипта зберігають свої значення між запитами: запитаємо цей скрипт кілька разів поспіль і отримаємо: 1 2 3 4 5 ...
без Apache :: Registry картина була б такою, зрозуміло: 1 1 1 1 + 1 ...
Не дивуйтеся, якщо відкривши нове вікно IE і повторивши процедуру ви знову отримаєте: 1 2 3 4 5 ... замість 6 7 8 9 10 .... Як правило на сервері працюють кілька дочірніх процесів httpd, кожен з них має свою копію вашого скрипта і відповідно свою копію $ i.
Команда httpd -x запустить сервер з одним дочірнім процесом - зручно для налагодження.
Нижче слідує приклад того, як писати НЕ ТРЕБА: досить одному користувачеві вказати вірні login-password, і всі інші зможуть заходити просто так :).
2. Певні в вашому скрипті функції стають вкладеними в зовнішнє функцію. Ось у що Apache :: Registry перетворює 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 інтерпретатором.
продуктивність
На моєму 300Celeron результати наступні: 774, 1039, 768 мілісекунд відповідно. Тобто під mod_perl скрипт виконався за 6мс (774-768), без mod_perl - за 71мс (1039-768). У 12 разів зросла прозводительности, однако! Для реальних скриптів ця цифра буде набагато меншою, звичайно.