Изменения

[[Изображение:Perl.appservers.benchmark.png|right|thumb|Тест производительности некоторых серверов]] В статье рассматриваются платформы/библиотеки для запуска веб-приложений на языке [[Perl]]. Рассматриваются они именно как «серверы приложений» — в случае со standalone серверами не предъявляется требований гибкости обычного HTTP-сервера вроде [http://nginx.ru nginx] или [http://httpd.apache.org/ Apache], безопасности, или производительности в обслуживании статических файлов, так как предполагается, что Perl-сервер будет всё равно «спрятан» за фронтенд наподобие nginx. Задача платформы — предоставить удобный программный интерфейс, такой, чтобы приложение могло получить запрос, предназначающийся ему, и сформировать на него адекватный ответ.

=== CGI , PCGI ===

# Универсальность — скрипт, написанный с использованием {{CPAN|запуск CGI|CGI.pm}}, будет работать на любой платформе, так как CGI поддерживают все (скриптов поддерживается почти все?).# Простые вещи реализовать на CGI просто. Чем-то эта идеология похожа на идеологию Perl в целом — простые задачи он делает простыми, а сложные — возможными.# Большое количество наработок, то есть, модулей для работы в CGI среде. В частности, к счастью разработчиков, есть модуль {{CPAN|PCGI|PCGI.pm}}, являющий собой вменяемую PHP-подобную реализацию CGI-протоколавезде.

А вот универсальность Универсальность CGI в смысле возможности использования произвольного языка программирования для нас ни плюсом, ни минусом, очевидно, не является, так как рассматривается именно Perl.

МинусыНа этом плюсы заканчиваются и начинаются сплошные минусы:

# Кривой Второй наиболее неприятный минус — очень неудобный API наиболее стандартного модуля {{CPAN|CGI|CGI.pm}}. Например:#* Нельзя нормально получить хеш со всеми параметрами, так как CGI->Vars работает криво: если в запросе передано несколько значений одного параметра (&a=1&a=2), то в Vars значением этого параметра будет конкатенация всех этих значений (то есть { a => '12' }). Хотя по логике вещей там должен быть массив [ '1', '2' ].#* CGI->cookie() не дружит с UTF-ными ключами.#* Следить за своевременным выводом заголовков и устаревший код многих модулей для работы текста ответа нужно самому.#* У различных функцих весьма странные интерфейсы — с разными функциями ключами, начинающимися на «-» и так далее.#* В CGIчасто даже передаются не все заголовки запроса.# Говнокод. Примеры:#* На код самого CGI.pm написан без использования страшно смотреть. В принципе, уже одно отсутствие <code>use strict</code>. Это не страшно, но показатель раздолбайства говорит о раздолбайстве авторов.#* В районе года 2000-ного авторам CGI.pm вдруг взбрело в голову, что век амперсанда (&) в качестве разделителя параметров в строках запроса подошёл к концу, и что теперь все будут использовать вместо него точку с запятой (;). Соответственно поведение и разбора, и генерации URL изменилось — причём, если в случае с генерацией всё легко возвращается на свои места заданием опции -oldstyle_urls, то разбор URL неизменно разбивает их и по «&», и по «;», что влечёт за собой различные неприятные эффекты.#* Многие модули Большинство модулей типа CGI::''xxчто-нибудь'' исповедуют  — дикая древность, исповедующая генерацию HTML кода без использования шаблонизаторов, обычными print()'ами, на содержимое которых повлиять без влезания в сами модули невозможно. ''XXI век на дворе, пора бы прекратить хотя бы это'' — ан нет, и в 2004, и даже в 2006 годах такие модули появлялись.# Идеология CGI хоть чем-то и похожа на Перл{{CPAN|PCGI}} — те же яйца, но фактически CGI больше рассчитан на простые задачитолько в профиль, нежели чем на сложные.# Слабые возможности взаимодействия чуть более аккуратно написанные и с HTTP-сервером — например, обычно в CGI даже не передаются все заголовки запросазащитой от слишком больших запросов. Кроме того, вывод ответа на STDOUT неудобен, если различные параметры задаются в различных местах программыВсе интерфейсные минусы сохраняются.

Идея [[rupedia:FastCGI|FastCGI]] — ликвидировать недостатки тормоза CGI, сохранив интерфейс. Главный недостаток CGI — необходимость перезапуска приложения, поэтому его и ликвидировали в первую очередь: FastCGI-процесс обрабатывает не один запрос, а много — последовательно принимая их в цикле через Unix- или TCP-сокет. Таким образом, FastCGI-процессы, во-первых, могут быть запущены на другом физическом сервере, а во-вторых, становится возможно распределение запросов между несколькими долгоживущими процессами.

[[rupedia:SCGI|SCGI]] — практически это фактически клон FastCGI, отличия лишь в формате передачи данных, который, как утверждают авторы, проще реализовать, но и возможностей у него меньше — например, STDERR не передаётся обратно HTTP-серверу. Поддерживается несколько чуть менее широко: [http://wiki.nginx.org/NginxNgxSCGIModule ngx_scgi_module], Apache, [http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModSCGI Lighttpd], [http://www.cherokee-project.com/ Cherokee], Mathopd с неофициальным [http://www.mail-archive.com/mathopd@mathopd.org/msg00369.html патчем].

# Взаимодействие по-прежнему ведётся через функции CGI, поэтому «интерфейсные» минусы CGI никуда не исчезают. Специальных обвязок для упрощения взаимодействия с сервером по протоколу FastCGI нет, кроме самой примитивной реализации — модуля {{CPAN|FCGI}}. ''Идеология, видимо, такова — а зачем, раз и так есть CGI.pm и компания?''

[http://perl.apache.org/ mod_perl] — модуль HTTP-сервера [http://httpd.apache.org/ Apache], предназначенный для веб-разработки внутри модулей Apache на языке Perl. Существуют как версии для Apache 1.x«Модулей» — потому, так и для 2.x. Внутреннее устройство что API mod_perl’а почти полностью повторяет C C’шное API апача. Поэтому же API сильно различается в 1-ой и 2-ой версиях. Хотя какая разница, всё равно про httpd 1.x и mod_perl 1.x уже никто не помнит.

# Очень большая Большая степень гибкости и возможности комбинирования с другими модулями Apache, в частности, засчёт наличия большого числа обработчиков разных стадий запроса. Гибкость означает, что можно не только просто отправлять ответ на запрос из своего Своим Perl-модуля, но модулем можно и осуществлять не всю обработку запроса, а, например, только авторизацию или ещё что-нибудь. Любопытный пример использования: [http://svn.yourcmc.ru/viewvc.py/vitaphoto/head/lib-sway/SVNPropCheck.pm?view=markup SVNPropCheck].# Весьма богатый и достаточно довольно удобный программный интерфейс, через который с Apache можно делать практически всё, что душа пожелает.# Возможность с небольшими телодвижениями запускать CGI-приложения в среде mod_perl с помощью модуля {{CPAN|Apache::Registry}}. Для примера использования доработанного модуля Registry можно посмотреть реализацию [http://mxr.mozilla.org/bugzilla/source/mod_perl.pl mod_perl.pl] из Bugzilla 3.x.# Модуль популярен. Есть множество наработок, многие из которых представляют собой весьма и весьма приятные продукты. Хороший пример — профилировщик {{CPAN|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.# Проблемы с перезагрузкой модулей в процессе обслуживания без перезапуска сервера. ''ОговоркаApache2:: это проблема Perl’а в целом, не только mod_perl’аReload — кривой; перезагрузку можно реализовать ручками (см. Но под mod_perl она проявляется сильнееhttps: //github.com/vitalif/bugzilla4intranet), но и такой вариант всё равно иногда при перезагрузке модулей ему прямо-таки «сносит крышу»срывает апачу крышу, он забывает про все константы и валит Internal Server Error на все запросыдо ближайшего рестарта. Ну и второе — авторы mod_perl могли бы и предусмотреть быстрый «сброс» интерпретаторов по сигналу.''# В «многопользовательской» среде, точнееБольшое потребление памяти, ибо Perl сосуществует в среде одних и тех же процессах с множеством различных веб-остальными модулями Apache.# Если нужно запустить несколько разных приложенийили несколько экземпляров одного приложения, мод_перл mod_perl создаёт проблемы по причине отсутствия изоляции загруженного кода модулей между приложениями. Решение для этого — Решается это PerlOptions +Parent(в mod_perl 1.x не решалось), но оно подходит только для случая с небольшим количеством приложений, так как в противном этом случае детёныши дочерние процессы Apache вырастают до совсем неприличных размеров по причине работы в них каждом нескольких пулов Perl-интерпретаторов вместо одного. Пул процессов-то общий.# Время от времени в mod_perl всплывают совершенно удивительные и неуловимые глюки, особенно в необычных режимах вроде [http://perldoc.perl.org/perlsec.html taint], и или при использовании с некоторыми модулями или движками Apache. ''«Потому что Perl и mod_perl — это как бэ немного разные языки»'' (c). Например:

#* При включённом taint mode и тоже в отдельном интерпретаторе, в составе [http://www.bugzilla.org/ Bugzilla] 3.x проявляется следующий мистический баг:

#* Ещё пример в taint mode из Багзиллы:#: Где-то в глубине души модифицированного модуля <code>Bugzilla::Field::Choice</code> конкатенируются <code>Bugzilla::Product->DB_COLUMNS->[0]</code> и <code>Bugzilla::Product->DB_TABLE</code>. При проверке {{CPAN|Scalar::Util}}::tainted в момент конкатенации сами по себе они оба безгрешны, однако, грех (флаг tainted) зарождается при их конкатенации. ''Вот и как это понимать? Адам и Ева сами по себе были безгрешны, но соединившись?..''# Некоторые затрудения в ''автоматизированных'' отладке и профилировании приложений в среде mod_perl из-за неочевидности программ исполнениякоманд запуска. Автоматизированные Многие инструменты эта неочевидность «смущает».

#: ''Как вы думаете, почему так широко распространился язык [[rupedia:PHP|PHP]]? Именно по причине простоты обслуживания.''

=== <s>ngx_http_perl_module </s> ===

Идея — вызов Perl-кода из [http://nginx.ru/ nginx]. Скорее мёртв, чем жив.

* Поразительное качество: невозможно получить список ''всех'' HTTP-заголовков, присутствующих в запросе, а можно лишь считывать их по одному. Остаётся только применять [http://svn.yourcmc.ru/viewvc.py/{{SVN|vitalif/trunk/scripts/nginx.xs.diff }} патч к src/http/modules/perl/nginx.xs].

У такого подхода — использования HTTP вместо встраивания интерпретатора в сервер, или вариаций на тему CGI — есть несколько приятных преимуществ. Фронтенд может балансировать и распределять по нескольким серверам нагрузку одновременно с передачей запроса, причём для этого существует множество готовых качественных инструментов. Работа администраторов упрощается, потому что конфигурация фронтенда для передачи запроса разным приложениям идентична, а сами приложения могут быть запущены под любым системным пользователем, на другом сервере, в jail’е, виртуальной машине, за аппаратным firewall’ом или внутри какой-нибудь другой системы безопасности. А при При отладке разработчик может взаимодействовать напрямую со своим приложением без необходимости запускать отдельный HTTP-сервер. Потребление памяти сокращается засчёт изоляции каждого придожения в своём наборе процессов.

=== LWP (HTTP::Daemon) {{CPAN|PSGI}}/{{CPAN|Plack}} ===

Можно смело сказать, что {{CPAN|LWPPSGI}} (''libwww-perl'') — библиотека для создания как клиентов, так и серверов, полностью совместимых со спецификацией HTTP/1[http://plackperl.1, на чистом Perl’еorg Plack] — самый современный и удобный интерфейс для Perl веб-приложений.

В качестве единственной готовойPSGI — Perl-реализация питонячьего [http://wsgi.readthedocs.org/ WSGI]. «Низкоуровневый» интерфейс взаимодействия тривиален:* Приложение = функция.* На входе 1 хешреф «окружения», пусть и исключительно простойв который включаются, платформыво-первых, исповедующей идеологию получения запросов параметры, аналогичные %ENV в форме HTTP:CGI (REQUEST_URI, PATH_INFO и т. п.)…* …а во-вторых, некоторые PSGI-специфичные ключи, например, «input», содержащий входной поток.* На выходе массив из 3-х элементов:Request численный статус ответа, массив заголовков в виде [ Header => Value, Header => Value, … ] и текст ответа HTTP::Response’ами можно рассмотреть . Однако без дополнительных обёрток такой интерфейс неудобен, поэтому есть {{CPAN|HTTP::Server::BrickPlack}}, построенный на основе HTTPпричём имеющий вполне вменяемый интерфейс — например, Plack::DaemonRequest->parameters возвращает в виде хеша все GET и POST параметры, Plack::Request->cookies — хеш кукисов и т. п. Это — в отличие от модулей типа CGI и PCGI, в которых параметры и куки нужно читать по отдельности через param() и cookie().

* Грамотный интерфейс без глобальных переменных.* Очень логичный и правильный программный интерфейс — {{CPAN|HTTPСовместимость с кучей разных серверов::Request}}можно запускать хоть под CGI/FastCGI (с помощью Plack), {{CPAN|HTTPхоть в Apache ([http::Response}}//github.com/spiritloose/mod_psgi/ mod_psgi]), {{CPAN|HTTPхоть в [https::Body}} и т//uwsgi-docs. пreadthedocs. HTTP::Bodyorg/ uWSGI], кстатихоть в виде standalone демона (Starman, Twiggy, Corona и т.п, полный список на http://plackperl.org). Причём, использует {{CPAN|Catalyst}}standalone-реализации по отзывам вполне производительны.

 * Главный минус в томРазве что отсутствие совместимости со «старыми» приложениями — то есть, что LWP нельзя просто обернуть CGI скрипт в качестве основы HTTP-сервера не использует, видимо, '''практически никто'''функцию и превратить его таким образом в PSGI. Посему* (Не проверено) возможно, сколь логичным бы ни выглядел сервер, получающий на вход HTTP::Request и отвечающий HTTP::Response’ами, реально готовых наработок для такого подхода фактически нетв PSGI серверах отсутствует поддержка перезагрузки модулей. Например* В остальном, нет ничего похожего на удобный Apache2::Requestпохоже, с готовыми функциями для доступа к запросу, разобранному на URI, параметры POST, заголовки и кукивсё хорошо.

* Существует некоторое количество модулей для расширения данного сервера — в частности, для запуска приложений Интерфейс — CGI. В режиме '''nph''' — «Non-Parsed Headers» — то есть на некоторых фреймворках через STDOUT нужно выводить просто HTTP::Server::Simple, например, для {{CPAN|Mason}}-ответ.* Модуль достаточно широко используется при тестировании веб-приложенийЭто устраняет часть интерфейсных ограничений CGI, в качестве легковесного тестового сервера: {{CPAN|Test::HTTP::Server::Simple}}сохраняя совместимость с CGI скриптами.

* Интерфейс — снова Интерфейс CGI с аналогичными FastCGI всё-таки требует по крайней мере выбора нужных модулей для разбора запросов и SCGI интерфейсными минусамиобъединения всего этого функционала в своём приложении.* Странная реализация parse_request() и parse_headers(), по меньшей мере, вплоть до версии 0.40 (можно полечить переопределением соответствующей функции).** Читает из стандартного ввода запрос и заголовки она по 1 символу функцией [http://perldoc.perl.org/functions/sysread.html sysread()], что весьма негативно сказывается на производительности.** В качестве разделителя строк, согласно всем стандартам, при обмене данными по сети, должно выступать сочетание CR-LF в платформо-независимом варианте: «\015\012». Тем не менее, функции HTTP::Server::Simple используют просто «\n», что тоже работает, но не является идеально переносимым вариантом.

== Заключение = <s>LWP (HTTP::Daemon)</s> ===

С точки зрения веб{{CPAN|LWP}} (''libwww-разработчикаperl'') — библиотека для создания как клиентов, не принимающего участие в разработке основного «ядра» системы (демона так исерверов, полностью совместимых со спецификацией HTTP/или обработчиков)1.1, всё вышеописанное сводится к следующим различным интерфейсам:на чистом Perl’е.

* [httpВ качестве единственной готовой, пусть и исключительно простой, платформы, исповедующей идеологию получения запросов в форме HTTP://perl.apache.org/docs/1.0/ mod_perl 1.x]* [http://perl.apache.org/docs/2.0/ mod_perl 2.x]* {{CPAN|CGI}}* {{CPAN|PCGI}}* Request и ответа HTTP::Response’ами можно рассмотреть {{CPAN|HTTP::RequestServer::Brick}} + {{CPAN|, построенный на основе HTTP::Response}}Daemon.

'''Если стремиться к наиболее «красивому» и логичному интерфейсу, тоПлюсы:'''

Всё, что существует — отстой. С моей точки зрения, по идеологии наиболее близок к идеалу подход LWP * Очень логичная и правильная '''идея''' программного интерфейса — {{CPAN|HTTP::ServerRequest}}, {{CPAN|HTTP::Brick — на входе объект «запрос»Response}}, на выходе объект «ответ»{{CPAN|HTTP::Body}} и т. Однако этот подход совсем не популяренп. (HTTP::Body, поэтому используя егокстати, вы обрекаете себя на разработку и поддержку своей реализации — никто не говорит, что это плохо, но… не mainstream.использует {{CPAN|Catalyst}})…

Минусы: * …Увы, оставшаяся без полной реализации.* Главный минус в том, что LWP в качестве основы HTTP-сервера не использует '''Если хочется простоты в стиле PHP, то:практически никто'''. Посему, сколь логичным бы ни выглядел сервер, получающий на вход HTTP::Request и отвечающий HTTP::Response’ами, реально готовых наработок для такого подхода фактически нет. Например, нет ничего похожего на удобный Apache2::Request, с готовыми функциями для доступа к запросу, разобранному на URI, параметры POST, заголовки и куки. == Заключение ==

Можно обратиться к PCGI«Финалистами» являются [http://perl.apache.org/docs/2.0/ mod_perl 2.x], {{CPAN|CGI}} и {{CPAN|Plack}}. Остальное распространено слабо.

'''А если выбирать Победитель — однозначно {{CPAN|Plack}}. Он наиболее универсальный и «mainstream» (широко поддерживаемый) интерфейссовременный, то:'''простой и продуманный.

ЭтоCGI — всё ещё жив, конечно же, '''CGI'''но безнадёжно устарел. Что и объясняет популярность FastCGI — эквивалентного наиболее простому интерфейсуСтарые приложения, обёрнутому на нём написанные, нужно либо превращать в FastCGI, либо превращать в «ускоритель». Если хочется — использовать HTTP::Server::Simple тоже можно, но только осторожно (достаточно удобно и сделано в https://github.com/vitalif/bugzilla-4intranet), либо, на крайний случай, просто запускать через {{CPAN|FCGI::Daemon}}.

Также следует помнить о всё ещё очень высокой популярности mod_perl. Ни mod_perl — тоже популярен, хотя ни универсальностью, ни надёжностью от него не пахнет, . «Perl и mod_perl — это нужно понимать, но всё-таки, во-первых, такой гибкости в обработке запросов невозможно добиться больше ни на одной платформе, а во-вторых, поддерживается он достаточно широко и поэтому вполне подходит для использованияразные языки».