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 (у нас собран).