13 521
правка
Изменения
→mod_perl
# Весьма богатый и достаточно удобный программный интерфейс, через который с Apache можно делать практически всё, что душа пожелает.
# Возможность с небольшими телодвижениями запускать CGI-приложения в среде mod_perl с помощью модуля Apache::Registry. Для примера использования доработанного модуля Registry можно посмотреть реализацию [http://mxr.mozilla.org/bugzilla/source/mod_perl.pl mod_perl.pl] из Bugzilla 3.x.
# Модуль популярен. Есть множество наработок, многие из которых представляют собой весьма и весьма приятные продукты. Пример — профилировщик [http://search.cpan.org/perldoc?NYTProf NYTProf], разработанный именно для профилирования мод_перла.
Минусы:
# Чрезмерная завязка на внутреннее устройство веб-сервера [http://httpd.apache.org/ Apache]. Фактически — когда вы разрабатываете на mod_perl’е, вы фактически разрабатываете ''полноценный модуль Apache''. Аналогично — приложения, написанные под mod_perl, не запустятся больше нигде.
# В mod_perl2 для различных функций существует по нескольку где-то конкурирующих, где-то дополняющих друг друга, а где-то сходных по функционалу, но разных по интерфейсу библиотек. Частично это диктуется совместимостью с mod_perl1. ''Примеры — куки: Apache2::Cookie, APR::Request::Cookie, запрос: Apache2::RequestRec, Apache2::RequestUtil, Apache2::Request, APR::Request. Пока я допёр, что для того, чтобы получить в пользование <code>$r->dir_config()</code>, нужно сделать <code>use Apache2::RequestUtil</code>...…'' Это не так страшно, но некоторую путаницу всё-таки вносит.
# Склонность к утечкам памяти. ''mod_perl течёт всегда, хоть ты его режь.'' Решение, правда, тоже несложное — MaxRequestsPerChild.
# Серьёзное увеличение размеров детёнышей процесса Apache.
# Проблемы с перезагрузкой модулей в процессе обслуживания без перезапуска сервера. ''Оговорка: это проблема Perl’а в целом, не только mod_perl’а. Но по крайней мере можно было бы предусмотреть быстрый «сброс» интерпретаторов по сигналу.''
# В "многопользовательской" «многопользовательской» среде, точнее, в среде с множеством различных веб-приложений, мод_перл создаёт проблемы по причине отсутствия изоляции загруженного кода модулей между приложениями. Решение для этого - этого — PerlOptions +Parent, но оно подходит только для случая с небольшим количеством приложений, т.к. так как в противном случае детёныши Apache вырастают до неприличных размеров по причине работы в них нескольких пулов Perl-интерпретаторов вместо одного.
# Время от времени в mod_perl всплывают совершенно неуловимые глюки, особенно в необычных режимах вроде [http://perldoc.perl.org/perlsec.html taint], и при использовании с некоторыми модулями или движками Apache. ''«Потому что Perl и mod_perl — это как бэ немного разные языки»'' (c). Например:
#* При использовании [http://mpm-itk.sesse.net/ mpm_itk], 2-го мод_перла и PerlOptions +Parent (дающей отдельный пул интерпретаторов виртхосту) глобальные переменные в пакетах (как my, так и our) перестают сохранять свои значения между запросами.
#:* Если же написать <code>s/[,\s]+/ /g for $oldstr, $newstr;</code>, то обе, как и положено, остаются не tainted.
#: Баг воспроизводится только в составе Bugzilla и только под мод_перлом, из контекста выдернуть его не получается.
# Некоторые затрудения в ''автоматизированных'' отладке и профилировании приложений в среде mod_perlиз-за неочевидности программ исполнения. Автоматизированные инструменты эта неочевидность «смущает».# Отсутствие mod_perl на подавляющем большинстве веб-хостингов. Потому что для админов серверов с кучами хомячков это - это — головная боль, в многопользовательской среде влекущая проблемы как с безопасностью, так и с надёжностью и производительностью. Всё по причине уже описанных минусов.
#: ''Как вы думаете, почему так широко распространился язык [[PHP]]? Именно по причине простоты обслуживания.''