mod_perl собран статически. Хочется иметь динамическую версию mod_perl.
Created attachment 599 [details] DSO mod_perl support Фичи патча: 1. release_tag выставляется в зависимости от дистрибутива (.M24, .M22, .J22, .C23) 2. Починена сборка под Master 2.2 (без mod_deflate) 3. Динамический mod_perl - появился пакет mod_perl-common от которого зависят и apache-perl и mod_perl, пакет apache-perl больше не obsoletes mod_perl. Возможно я что-то не учёл с зависимостями... Паекет корректно собирается в sandman на Sisyphus недельной давности, Master 2.2 и Master 2.4 без правки спека.
Какой послушный мальчик. Ну как такое не принять :-) Будет в следующей сборке, но она -- не раньше конца месяца. Если хочешь, можешь сделать NMU.
(In reply to comment #2) > Какой послушный мальчик. Ну как такое не принять :-) ;-))))) > Будет в следующей сборке, но она -- не раньше конца месяца. Если хочешь, можешь > сделать NMU. NMU делать пока рано. conf/addon_modules/mod_perl.conf пока пустой, наверно имеет смысл перенести его в mod_perl-common и вынести туда всё perl-специфичное. Ну и более трезвым взглядом посмотреть на зависимости... P.S. А фишка с release_tag мне понравилась...
Ещё один момент - apache_release не получится делать в виде altN.M, потому как alt10.M22 будет больше чем alt10.1.M22...
Эээ... если оно тебе нужно, то допинать до разума всё равно у тебя скорее выйдет быстрее (и пульнуть, например, в Daedalus). У меня дедлайны, события и командировки до конца месяца расписаны...
(In reply to comment #5) > Эээ... если оно тебе нужно, то допинать до разума всё равно у тебя скорее выйдет > быстрее (и пульнуть, например, в Daedalus). Не вопрос. Протестирую и задедалю.
Created attachment 600 [details] DSO mod_perl support Oops. Typo...
Сэр, это работает или про него-то матюки на канале и раздавались потом?
ЭТО не работает. Сегфолтится при первом обращении к апачу вообще. Почему - неизвестно.
"Так бы сразу и сказал, та-ак бы сразу и сказал..."
Друзья, а зачем нам DSO mod_perl если он принципиально работать стабильно не будет? Глючный этот модуль. Очень глючный. И написан кривыми руками. И имеет свойство подтекать, особенно когда собран DSO. А самое главное -- все преимущества mod_perl (а именно сохранение значений переменных между запросами) работают тогда, и исключительно тогда, когда копий mod_perl _мало_. Как только их становится много, то Apache начинает просто впустую жрать память. Поэтому mod_perl можно и нужно пускать только за reverse proxy, как у нас сейчас и сделано. Любое другое решение будет менее надёжным и гораздо менее производительным.
(In reply to comment #9) > ЭТО не работает. Сегфолтится при первом обращении к апачу вообще. Почему - > неизвестно. Я не знаю как вы его собираете, но у меня на трех обсизифленых хостах стоит mod_perl as DSO и не жужжит (в смысле не падает). "Что я делаю не так?" (с)
У вас много лишней памяти? Подарите их мне. А я вас правильно соберу mod_perl (без всяких DSO) и сэкономлю память увеличив производительность. Честно-честно.
(In reply to comment #13) > У вас много лишней памяти? Подарите их мне. А я вас правильно соберу mod_perl > (без всяких DSO) и сэкономлю память увеличив производительность. Честно-честно. И прикрутите туда мне пхп? Буду рад...
Зачвем? PHP есть во фронтенде. А апач с mod_perl и апач с mod_php4 надо совсем по-разному настраивать. У первого должно быть совсем-совсем мало child'ов. Иначе будет впустую жрать память, да ещё и не давать полноценного увеличения производительности.
(In reply to comment #15) > Зачвем? PHP есть во фронтенде. А апач с mod_perl и апач с mod_php4 надо совсем > по-разному настраивать. У первого должно быть совсем-совсем мало child'ов. Иначе > будет впустую жрать память, да ещё и не давать полноценного увеличения > производительности. В моей ситуации абсолютно нет смысла держать фронтенд. 99% запросов обрабатываются мод_перлом, 1% - пхп. Ладно, значит буду жить по-старинке.
Фронтенд нужен даже если 100% обрабатывается mod_perl. Потребление памяти уменьшится в разы, скорость обработки тоже, эффективность от кэширования значений переменных внутри mod_perl скриптов станет ещё заметнее.
. o O ( fastcgi )
Что ты имеешь в виду?
Что промышленная перловка, виденная мной, сделана и живёт в основном под FastCGI.
Что характерно -- я очень серьёзно думаю переползать целиком под FastCGI. Это у меня часть борьбы с уменьшением использования апача. IMHO ветка 2.0 пошла куда-то не понятно куда. 1.3.* тормоз и недостаточно удобна. Хостерам это, конечно, необходимость, но свои личные проекты уже предпочитаю частично уводить из под апача. После того как я увидел что установка простого реверс-прокси в разы уменьшает потребление оперативки и процессора -- ну его нафиг. Посему FastCGI рулит :)
> После того как я увидел что установка простого реверс-прокси в разы уменьшает > потребление оперативки и процессора -- ну его нафиг. Посему FastCGI рулит :) Кстати, а реверс-прокси через mod_proxy или чем другим?
Именно. Хотя про mod_accel где-то рядом висело, и bloodmary@ спрошала, помнится...
Реверс-прокси лучше всего делать nginx. А на апаче нужен mod_realip (у нас собран).
