После двух лет разработки доступна (http://perl.apache.org/download/index.html) новая версия Apache-модуля mod_perl 2.0.9 (http://perl.apache.org). Mod_perl позволяет интегрировать интерпретатор Perl в http-сервер Apache и увеличить скорость выполнения динамического контента на Perl за счёт кэширования его байткода, а также обеспечить низкоуровневый доступ perl-скриптов ко внутренностям Apache, в том числе даёт возможность создавать модули на языке Perl, управлять конфигураций, обрабатывать все стадии прохождения запроса.Новая версия примечательна добавлением поддержки Apache httpd 2.4.x и переходом на новую модель распределения памяти при работе в системах с многопоточными MPM. В остальном в выпуске представлены мелкие улучшения и исправления проблем, например, устранены проблемы со сборкой в GCC 5. Выпуск Perl 5.22.x пока не поддерживается, его поддержка ожидается в mod_perl 2.0.10.
URL: http://perl.apache.org/download/index.html
Новость: http://www.opennet.me/opennews/art.shtml?num=42460
Вообще актуальные ребята. Perl для Web умер примерно лет 8-10 назад. Apache на боевых серверах я не видел уже лет 5 точно.
а что ты видел на боевых серверах? IIS?
nginx +
Если хостинг не шаровый и php, то щас это php-fpm обычно.
А про всякие джанги и рельсы с нодой и говорить нечего, нафиг им апач вообще сдался...
Ты не поверишь...
Ага, эту новость на нтв крутить
http://slonik-v-domene.livejournal.com/99505.html
http://slonik-v-domene.livejournal.com/141951.html
http://slonik-v-domene.livejournal.com/142305.html
Pike ну вот почему из кучи статей в интернете ты выбрал статьи аффтара - самого тупого и самоуверенного индюка вся Рунета?! Ну ведь даже не смех сквозь слёзы, а просто спазмы хохота от его статей... Не понимаю.
Ну я ж не виноват что он такой. Да не детей с ним крестить.
В данном случае зерно истины в его словах присутствует.
TL;DR http://plumqqz.livejournal.com/292784.html?thread=3104688#t3...
> nginx +
> Если хостинг не шаровый и php, то щас это php-fpm обычно.
> А про всякие джанги и рельсы с нодой и говорить нечего, нафиг
> им апач вообще сдался...В общем-то если ты их не видел, это не значит что их нет. Корпоративные клиенты в отличии от хипстеров-стартаперов больше доверяют стабильному (читай старому как гогно мамонта, коду). Корпоративных клиентов ооооочень много.
И правильно делают. Большинству корпоративных клиентов надо чтоб работало, а не чтоб весело было играться в процессе очередного переизобретения всего.
Как всегда истина где-то посредине. NGINX, благодаря своей асинхронности по-умолчанию, будет попроизводительней апача, но с другой стороны те, кому нужна производительность, поставят себе железный балансировщик, тем, кому она не нужна, будут сидеть на голом апаче, хипстеры будут мастурбировать на всё новое. Из реальных кейсов:
-Нжинкс не даёт прироста просто потому что бэкэнд очень медленный
-Нам не нужен нжинкс, у нас бэкэнд нацелен на точность обработки данных и нам нужна их гарантированная доставка и обработка, потому производительность где-то на заднем плане
-Мы не доверяем быстрорастущим проектам
-Сайтам-визиткам вообще не нужна производительность.
Вы всё в кашу смешали.> NGINX, благодаря своей асинхронности по-умолчанию, будет попроизводительней апача
В качестве фронтенда-балансера, но и только.
> кому нужна производительность, поставят себе железный балансировщик
Типа F5? Там внутри не очень железно, и очень криво. Кто-то поставит, конечно, но совсем не из-за производительности.
> тем, кому она не нужна, будут сидеть на голом апаче
Либо карьерный самосвал, либо детский самокат, третьего не дано. Интересный у вас взгляд на мир.
Дальнейший поток сознания не смог прокомментировать по причине трезвости.
Надо признать, что на нашем хостинге тоже процентное соотношение apache httpd против остальных ощутимо снижается. Для Ruby используют свои приблуды, на golang тоже обычно свой встроенный сервер, php потихонечку мигрируется на hhvm (который висит отдельно и обслуживается через nginx), для java используют apache tomcat… и т.д.
Очень похоже на зоопарк недо-make-ов.
На каждом языке надо обязательно запилить своё, ни с чем несовместимое, кривое и с квадратными колёсами.
А то неудобно как-то - язык есть, а собственной системы сборки (написанной, конечно, на нём же) нет. Засмеют же.
> Очень похоже на зоопарк недо-make-ов.
> На каждом языке надо обязательно запилить своё, ни с чем несовместимое, кривое
> и с квадратными колёсами.
> А то неудобно как-то - язык есть, а собственной системы сборки (написанной,
> конечно, на нём же) нет. Засмеют же.Тут проблема немного в другом. Например куда в apache httpd вы будете пихать Java-вские War-ы? Или например принято считать, что у golang бешеный parallelism и concurancy [1], так почему бы это не использовать для обработки http-запросов? Да и вообще так было проще для программистов на Go, IMO. И т.д.
[1] http://benchmarksgame.alioth.debian.org/u64q/performance.php...
P.S.: Вообще очень иронично слышать от Rob-а Pike-а такого рода критику в сторону Go :)
Кстати говоря, вы действительно считаете, что apache2 httpd -- это разумное решение в наше время?P.S.:
> concurancyНе проспался, имелось в виду: "concurrency".
А ты хоть знаешь что такое cpan?
Или сколько книг написано по perl.
Не скоро php и python догонят perl.
А mod_perl есть альтернатива достойная и на столько же стабильная?
Для начала почитай что это вообще такое, а потом... молчи.
> А mod_perl есть альтернатива достойная и на столько же стабильная?есть протокол PSGI, мне очень нравится как это сделано в uwsgi. перешёл на него с мод-перла. протокол стабилен. фреймворк у меня свой :)
Perl для Web нисколько не умер. Да и Апач тоже.
Я для своих django-проектов использую apache2 + mod_wsgi. Просто конфигурируется, ничего не сбоит.
Непатриотично же. nginx - нашевсё.
Патриотично же вообще интернет не использовать.
> Я для своих django-проектов использую apache2 + mod_wsgi. Просто конфигурируется, ничего
> не сбоит.Ну, признаться честно, связка gunicorn/uwsgi + nginx тож довольно таки хорошо и стабильно работает. Кому что нравится, на самом деле.
А Канаду ты видел когда-нибудь? Вдруг её тоже не существует?
> А Канаду ты видел когда-нибудь? Вдруг её тоже не существует?Я знал что я всего лишь горстка байт в виртуальной реальности! Спасибо Морфеус!
ну и зачем такую ерунду говорить ;-) и то и другое осталось на своих позициях, причем apache более чем
Ты не поверишь, но mail.ru, booking.com и многие другие с тобой не согласятся. Гугли psgi/plack, mojolicoious и dancer2
Perl может и не умер, но вот mod_perl точно гнать надо отовсюду с^#ной метлой. Какие иногда под ним баги происходят, не воспроизводимые в голом перле... А как его глючит при включении перезагрузки модулей... А как он течёт и сколько памяти жрёт, особенно если несколько приложений с PerlOptions +Parent в одном апаче гонять... Ужос, нах.Я в багзиллу вместо него впилил pure-perl HTTP сервер на основе HTTP::Server::Simple.
А ещё более правильный подход - это Plack/Starman. Тоже pure-perl + API на замену дебильному CGI.
Причём эти баги там всю жизнь были, и пользоваться этой штукой не рекомендовалось. FastCGI - наше всё.
> Причём эти баги там всю жизнь были, и пользоваться этой штукой не рекомендовалось. FastCGI - наше всё.Сколько пользуюсь и копаюсь в modperl - ниразу не видел баги. Дайте пример того как воспроизвести баги и я с ними разберусь.
"Багами в mod_perl" издревле было принято называть вот это, упомянутое "ой, оно ведёт себя не так как под голым перлом!". Причём в документации описано что именно так себя ведет, как именно не так и почему.Хотя баги были - и во времена апача 1.3, и пока второй был сырой (довольно долго). И сейчас что-то по мелочи наверное осталось, как в любом софте.
> "ой, оно ведёт себя не так как под голым перлом!"Так что именно? Я с modperl2 очень хорошо разобрался и местами даже восхищаюсь им как и архитектурой apache (nginx на фоне apache выглядит "безголосой попсой").
Это не ко мне вопрос, но обычно - начиная прямо с классики - https://perl.apache.org/docs/2.0/user/troubleshooting/troubl...
> но обычно - начиная прямо с классики - https://perl.apache.org/docs/2.0/user/troubleshooting/troubl...Ну тут ничего необычного, детские болезни новичков. Это не проблема.
>Дайте пример того как воспроизвести баги и я с ними разберусь.Ха-ха-ха. Какой гонор.
Возьмите mod_perl + CGI.pm. Попробуйте, для начала, 404 ответ со своим контентом выдать.
Потом сделайте контент размером более 8кб. Удивитесь разнице в поведении.
Не забудьте посмотреть, какой статус логируется в access-лог, и какой код ответа идет браузер. Удивитесь несоответствию в определенном сочетании модулей и размера ответа.Пойдем дальше. Включите/выключите mod_deflate apache-2.2. Проведите те же самые тесты.
Попробуйте выдать свой код ответа, отличный от 2хх/3хх, например собственную 500-ю...
Порадуйтесь тому, как просто это всё удается.Удачи в разбирательствах с багами.
> Ха-ха-ха. Какой гонор.Вот обязательно свои быдлячьи манеры показыва? - Хотя чего это я...но по порядку.
Вы не понимаете к чему я спросил, но интерпретировали мое заявление наихудшим образом, и позволили опубликовать себе эту оценку. Но раз вы позволили опубликовать свою оценку, то и я сделаю то же самое уже в ваш адрес. Я вас за язык не тянул.1. Я на самом деле баги не ловил с modperl, т.к., думаю очевидно что с CGI.pm под modperl не работаю.
2. Мне важно понимать сильные и слабые стороны используемого мной инструментария, и по возможности я стараюсь улучшить эти инструменты. Именно по этой причине я:
- работаю только с opensource, причем только с copyleft-программами, библиотеками и модулями
- шлю патчи авторам модулей на CPAN
- я запросил пример чтобы воспроизвести баги под modperl.Будь вы умнее - вы бы не стали публиковать столь линейно-бестолковую интерпретацию незнакомого человека.
Будь вы умнее - вы бы не стали навязывать быдлячьи черты незнакомым людям.Итого: по вашему поведению я в вас обнаружил существо с быDлообразным поведением по умолчанию. А это сильная черта недостатка интеллекта. Но вы можете мне не верить.
Теперь по делу.> Возьмите mod_perl + CGI.pm. Попробуйте, для начала, 404 ответ со своим контентом выдать.
Потом сделайте контент размером более 8кб. Удивитесь разнице в поведении. Не забудьте посмотреть, какой статус логируется в access-лог, и какой код ответа идет браузер. Удивитесь несоответствию в определенном сочетании модулей и размера ответа.
Ничего конкретного как воспроизвести, но я поймал одну проблему с ~8кб порогом когда на определенный вызов контент рендерится 2 раза. Однако проблем со статусами и ответом в логах не увидел. Была бы конкретика с примером и конфигурацией сервера - другое дело. А пока разбираюсь той непоняткой которую нашел.
> Пойдем дальше. Включите/выключите mod_deflate apache-2.2. Проведите те же самые тесты.
> Попробуйте выдать свой код ответа, отличный от 2хх/3хх, например собственную 500-ю...Порадуйтесь тому, как просто это всё удается.
не поймал проблемы (я наверное как-то "не правильно" использую все это), опубликуйте конкретику с примером и конфигурацией сервера
> Удачи в разбирательствах с багами.
Да не проблема, мне бы их воспроизвести. Пришлите примеры в студию. Если что, у меня apache 2.10 / Debian Jessie
>[оверквотинг удален]
> опубликовать свою оценку, то и я сделаю то же самое уже
> в ваш адрес. Я вас за язык не тянул.
> 1. Я на самом деле баги не ловил с modperl, т.к., думаю
> очевидно что с CGI.pm под modperl не работаю.
> 2. Мне важно понимать сильные и слабые стороны используемого мной инструментария, и
> по возможности я стараюсь улучшить эти инструменты. Именно по этой причине
> я:
> - работаю только с opensource, причем только с copyleft-программами, библиотеками и модулями
> - шлю патчи авторам модулей на CPAN
> - я запросил пример чтобы воспроизвести баги под modperl.Да я переанализировал половину кода mod_perl + изучил историю бага, про который говорю.
На него жаловались в течении 10 лет, но всем было пофиг. Было пофиг в то время, когда проект был живым. Теперь же, когда в нем жизнь теплится еле-еле, менять что-то вряд ли кто-то будет. Так что ваше заявление "и я с ними разберусь" вызывает только ....
Ну я разобрался.. Разберетесь и вы. Разберетесь в смысле "смогу понять что не так". А что-то в проекте изменится? Нет, я в это не верю.Не нравится CGI.pm ? Ну так проблема не в нем. Вот вам тесткейс, в нем нет CGI.pm.
Используемые версии ПО:
perl-5.14.2-21+deb7u2
apache2-2.2.22-13+deb7u4 (prefork)
libapache2-mod-perl2-2.0.7-3Конфиг подключения mod_perl:
<Location /perl>
Sethandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
</Location>
Скрипт:#!/usr/bin/perl -w
use strict;print "Status: 404 Not Found\n";
print "Content-Type: text/html; charset=windows-1251\n\n";
print "404 NOTFOUND: SMALL RESPONSE";
print '*' x 8192; #Включением-выключением строчки меняем общий размер ответа.
1) Апач + включенный модуль deflate, ответ >8k:Вместо сгенерированного контента видим стандартный ответ апача.
Content-Type: text/html; charset=iso-8859-12) Апач + включенный модуль deflate, ответ <8k:
Возвращается только ответ из скрипта
Content-Type: text/html; charset=windows-12513) Апач + выключенный модуль deflate, ответ >8k:
Возвращается ответ из скрипта + стандартный 404-ответ апача.
Content-Type: text/html; charset=windows-1251Стандартный ответ от апача можно выключить добавлением в скрипт двух строк кода:
my $r = Apache2::RequestUtil->request;
$r->status(-2); # Const DONE == -2
#$r->status(0); # Const OK == 0Но тогда в лог будет записано значение кода ответа 200, хотя в браузер пойдет требуемое 404. Вот такая веселуха.
4) Апач + выключенный модуль deflate, ответ < 8k:
Возвращается только ответ из скрипта
Content-Type: text/html; charset=windows-1251
> Да не проблема, мне бы их воспроизвести. Пришлите примеры в студию. Если
> что, у меня apache 2.10 / Debian JessieПримеры прислал. Думаю, что воспроизведется и на более свежих версиях, чем у меня, т.е. и на указанных вами.
Или Plack/uwsgi, Plack/FCGI, Plack/mod_psgi, ...
Согласен по всем пунктам. Единственно, чаще всего, для решений на perl, используют nginx-фронт и mojolicious на back-end.А Perl на shared-хостингах - это, преимущественно, CGI скрипты. Для решения конкретных задач проекта, не более.
Причём всё что делает этот back-end на mojo - это заворачивает ответы БД в JSON.
Смысл каковой деятельности примерно сводится к
>Программисту предоставляется возможность вместо работы с незнакомым высокоуровневым декларативным языком иметь дело со знакомым низкоуровневым процедурным. В итоге в описании результата "херово работает" удивление, по сути, должно вызывать не "херово", а "работает"
> Причём всё что делает этот back-end на mojo - это заворачивает ответы БД в JSON.Расскажи, что именно в mojolicious относится к этой деятельности. Ну кроме возможности выдавать ответы в том числе и в json. Встроенной работы с БД там нет, дефолтный рендер там html шаблоны, а не json.
Может ты с рельсами попутал или еще каким фреймворком, который делает 90% работы нужной для типичного веб приложения?
> дефолтный рендер там html шаблоны, а не jsonХорошо, поправка - я имел в виду "в лучшем случае - в JSON заворачивать". Про HTML-шаблоны в 2015 году было бы слишком грубо сразу вот так думать о людях плохо.
JSON плохо, HTML плохо. В каком же виде должен выдавать по твоему мнению результаты вебфреймворк?
Ну и ты проигнорировал суть вопроса, повторю его еще раз: "Что в mojolicious есть такого, что делает его пригодным только для заворачивания ответов БД в JSON?".
> JSON плохо, HTML плохо. В каком же виде должен выдавать по твоему мнению результаты вебфреймворк?JSON - хорошо. И HTML иногда нужен.
Вебфреймворк ничего не должен выдавать ни в каком виде по причине полной собственной ненужности в подавляющем большинстве случаев.
Ну так сразу бы и сказал, что считаешь ВСЕ вебфреймворки ненужными. Случай тяжелый, но хотя бы понятный и дальнейших вопросов не вызывает.
Руки кривые. Вот и память течет!!!
Английский нужно учить и мануалы до конца дочитывать и ничего не будет течь.
PerlOptions +Parent - это mod_perl????
mpm слыхал такое?
Голый perl - это как?
> После двух лет разработки доступна новая версия Apache-модуля mod_perl 2.0.9ну наконец-то, а я то я малось заждался..
> Новая версия примечательна добавлением поддержки Apache httpd 2.4.x...А 2.0.8 не работал что ли? Попробовал поставить на бубунте 14.04 mod_perl 2.0.8, а он тоже работает с апачей 2.4.x.
Все ставилось из бубунтийских реп. Насильно ничего впихивать не пришлось. В логах апачи при старте выдается: Apache/2.4.7 (Ubuntu) mod_apreq2-20090110/2.8.0 mod_perl/2.0.8 Perl/v5.18.2 configured
А вы потрудитесь, посмотрите как, кто и откуда есть пошла в 2.0.8 поддержка apache 2.4. Если кратко - нет, не работало, до неофициального патча от апачевцев.
писал на модперле больше 5 лет. в итоге, когда понял, что он таки "всё", перешёл на nginx+uwsgi, нисколечко не жалко. избавился от кучи багов, часть которых были от APR.ненужнисты и неосисляторы -- встать в угол и молчать полчаса.
Выше в комментариях уже просили привести примеры багов, но как-то реального примера никто так и не привел. :( Приведите пожалуйста примеры "кучи багов".Я не ради праздного интереса спрашиваю, у меня есть несколько сайтов, которые работают с использованием mod_perl.
навскидку знаю два. разбор не совсем корректных кук и явный бинарный utf-8 в теле запроса POST. для обоих потребовались воркэраунды в приложении. про куки в чём их некорректность не могу сказать, кроме того, что они не парсились модулем Apache2::Cookie и, кажется, это роняло воркера. я просто на стэковерфлоу нашёл ответ и применил их воркэрануд. для решения второго пришлось написать разбор реквеста самостоятельно. запрос такой приходил в уведомлении от платёжной системы, код которой я не мог поменять. что не отменяет, конечно, странного факта наличия русского имени "Всеволод" на карте виза.
уточните версии модулей и окружения которое использовалось чтобы попробовать воспроизвести
> уточните версии модулей и окружения которое использовалось чтобы попробовать воспроизвестистандартный debian7. http://stackoverflow.com/questions/8594363/expected-token-no...
про второй баг я, кажется, ничего толком в интернете не нашёл, догадался о его сути только через запись сырых приходящих данных.
> Выше в комментариях уже просили привести примеры багов, но как-то реального примера
> никто так и не привел. :( Приведите пожалуйста примеры "кучи багов".
> Я не ради праздного интереса спрашиваю, у меня есть несколько сайтов, которые
> работают с использованием mod_perl.у меня тоже есть сайты на мод-перл, они работают и будут ещё долго работать. но затянутость поддержки апач2.4, я уверен, заставила многих понервничать, а слабонервных сбежать. в дебиан7 не включили апач2.4 изза неготовности мод-перла для него. но когда он не был готов к релизу дебиан8, то это было уже красным флажком. что там в итоге включено в дебиан8 я не знаю, но по жалобам народа торопиться с переходом было рано. один из приятных моментов перехода на uwsgi -- мой тривиальный бенчмарк кардинально ускорился. про два бага, что задели меня лично, я уже написал. плюс, перейдя на psgi, я избавился от привязки к апачу, стало можно запускаться под любым (почти) psgi-сервером. на мод-перле у меня было написано столько своих надстроек, что, когда я полностью сменил платформу, приложения было очень легко портировать.
читал так же про баги в каких то странных местах мод-перла, которые мне ни разу не были нужны. так что на них мне было плевать.
ещё, его интегрированность оставляет вопросы. например, мне нужно было динамически добавлять ServerName в виртуалхост. это оказалось невозможно. все виртуалхосты шарят один и тот же пул интерпретаторов перла, следовательно набор модулей и их инициализированность -- попробуйте иметь два разных инстанса синглтонов $log4perl, например. это требует по сути разных инстансов апачей, что уже не так просто конфигурировать.
в копилку недостатков могу добавить невозможность лёгкой реализации вебсокетов. но это уже передовая веб-строительства, это точно не про мод-перл.
> мне нужно было динамически добавлять ServerName в виртуалхост. это оказалось невозможноя в свое время успешно реализовал конфигурацию "на лету", может это поможет: http://perl.apache.org/docs/2.0/api/Apache2/PerlSections.htm...
> все виртуалхосты шарят один и тот же пул интерпретаторов перла
http://perl.apache.org/docs/2.0/user/config/config.html#C_Pa...
>> мне нужно было динамически добавлять ServerName в виртуалхост. это оказалось невозможно
> я в свое время успешно реализовал конфигурацию "на лету", может это поможет:
> http://perl.apache.org/docs/2.0/api/Apache2/PerlSections.htm...это, как мне кажется, решает другую задачу. мне надо было управлять ServerName без перезагрузки апача. ну, точнее, мне так хотелось. на мой вопрос Torsten Förtsch предложил мне заимплементить не доделанную функциональность.
>> все виртуалхосты шарят один и тот же пул интерпретаторов перла
> http://perl.apache.org/docs/2.0/user/config/config.html#C_Pa...мне было не актуально, но спасибо, мысленно вычеркну этот пункт из недостатков :)
> это, как мне кажется, решает другую задачу. мне надо было управлять ServerName без перезагрузки апача. ну, точнее, мне так хотелось. на мой вопрос Torsten Förtsch предложил мне заимплементить не доделанную функциональность.Не совсем. Сейчас уже детали не вспомню, но я как раз делал динамическое управление виртуальными хостами (в т.ч. и задание ServerName) и у меня работало.
ну я как-то выкрутился в итоге тоже, но точно помню, что в 2009г, когда мне это было нужно, не нашёл прямого способа для этого. список рассылки мод-перла мне так же не помог.