Bug 5263 - Build DSO mod_perl
: Build DSO mod_perl
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/apache)
: unstable
: all Linux
: P2 enhancement
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2004-10-01 08:30 by
Modified: 2005-07-15 11:46 (History)


Attachments
DSO mod_perl support (9.17 KB, patch)
2004-10-01 08:34, Sir Raorn
no flags Details | Diff
DSO mod_perl support (9.17 KB, patch)
2004-10-01 11:49, Sir Raorn
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-10-01 08:30:08
mod_perl собран статически. Хочется иметь динамическую версию mod_perl.
------- Comment #1 From 2004-10-01 08:34:11 -------
Created an attachment (id=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 без правки спека.
------- Comment #2 From 2004-10-01 08:41:49 -------
Какой послушный мальчик.  Ну как такое не принять :-)

Будет в следующей сборке, но она -- не раньше конца месяца.  Если хочешь,
можешь
сделать NMU.
------- Comment #3 From 2004-10-01 08:47:30 -------
(In reply to comment #2)
> Какой послушный мальчик.  Ну как такое не принять :-)
;-)))))

> Будет в следующей сборке, но она -- не раньше конца месяца.  Если хочешь, можешь
> сделать NMU.
NMU делать пока рано.  conf/addon_modules/mod_perl.conf пока пустой, наверно
имеет смысл перенести его в mod_perl-common и вынести туда всё perl-специфичное.
Ну и более трезвым взглядом посмотреть на зависимости...

P.S. А фишка с release_tag мне понравилась...
------- Comment #4 From 2004-10-01 08:48:48 -------
Ещё один момент - apache_release не получится делать в виде altN.M, потому как
alt10.M22 будет больше чем alt10.1.M22...
------- Comment #5 From 2004-10-01 08:52:42 -------
Эээ... если оно тебе нужно, то допинать до разума всё равно у тебя скорее
выйдет
быстрее (и пульнуть, например, в Daedalus).

У меня дедлайны, события и командировки до конца месяца расписаны...
------- Comment #6 From 2004-10-01 08:57:26 -------
(In reply to comment #5)
> Эээ... если оно тебе нужно, то допинать до разума всё равно у тебя скорее выйдет
> быстрее (и пульнуть, например, в Daedalus).
Не вопрос. Протестирую и задедалю.
------- Comment #7 From 2004-10-01 11:49:38 -------
Created an attachment (id=600) [details]
DSO mod_perl support

Oops. Typo...
------- Comment #8 From 2005-01-29 21:36:33 -------
Сэр, это работает или про него-то матюки на канале и раздавались потом?
------- Comment #9 From 2005-01-30 15:08:43 -------
ЭТО не работает.  Сегфолтится при первом обращении к апачу вообще. Почему -
неизвестно.
------- Comment #10 From 2005-01-30 15:51:26 -------
"Так бы сразу и сказал, та-ак бы сразу и сказал..."
------- Comment #11 From 2005-01-30 17:34:27 -------
Друзья, а зачем нам DSO mod_perl если он принципиально работать стабильно не
будет?

Глючный этот модуль. Очень глючный. И написан кривыми руками. И имеет свойство
подтекать, особенно когда собран DSO.

А самое главное -- все преимущества mod_perl (а именно сохранение значений
переменных между запросами) работают тогда, и исключительно тогда, когда копий
mod_perl _мало_. Как только их становится много, то Apache начинает просто
впустую жрать память.

Поэтому mod_perl можно и нужно пускать только за reverse proxy, как у нас
сейчас
и сделано. Любое другое решение будет менее надёжным и гораздо менее
производительным.
------- Comment #12 From 2005-01-31 10:26:59 -------
(In reply to comment #9)
> ЭТО не работает.  Сегфолтится при первом обращении к апачу вообще. Почему -
> неизвестно.

Я не знаю как вы его собираете, но у меня на трех обсизифленых хостах стоит
mod_perl as DSO и не жужжит (в смысле не падает).
"Что я делаю не так?" (с)
------- Comment #13 From 2005-01-31 17:43:02 -------
У вас много лишней памяти? Подарите их мне. А я вас правильно соберу mod_perl
(без всяких DSO) и сэкономлю память увеличив производительность. Честно-честно.
------- Comment #14 From 2005-01-31 17:56:00 -------
(In reply to comment #13)
> У вас много лишней памяти? Подарите их мне. А я вас правильно соберу mod_perl
> (без всяких DSO) и сэкономлю память увеличив производительность. Честно-честно.

И прикрутите туда мне пхп? Буду рад...
------- Comment #15 From 2005-01-31 18:44:16 -------
Зачвем? PHP есть во фронтенде. А апач с mod_perl и апач с mod_php4 надо совсем
по-разному настраивать. У первого должно быть совсем-совсем мало child'ов.
Иначе
будет впустую жрать память, да ещё и не давать полноценного увеличения
производительности.
------- Comment #16 From 2005-01-31 19:18:28 -------
(In reply to comment #15)
> Зачвем? PHP есть во фронтенде. А апач с mod_perl и апач с mod_php4 надо совсем
> по-разному настраивать. У первого должно быть совсем-совсем мало child'ов. Иначе
> будет впустую жрать память, да ещё и не давать полноценного увеличения
> производительности.

В моей ситуации абсолютно нет смысла держать фронтенд. 99% запросов
обрабатываются мод_перлом, 1% - пхп.
Ладно, значит буду жить по-старинке.
------- Comment #17 From 2005-01-31 19:27:04 -------
Фронтенд нужен даже если 100% обрабатывается mod_perl.
Потребление памяти уменьшится в разы, скорость обработки тоже, эффективность от
кэширования значений переменных внутри mod_perl скриптов станет ещё заметнее.
------- Comment #18 From 2005-01-31 19:36:15 -------
. o O ( fastcgi )
------- Comment #19 From 2005-01-31 20:24:07 -------
Что ты имеешь в виду?
------- Comment #20 From 2005-01-31 21:51:46 -------
Что промышленная перловка, виденная мной, сделана и живёт в основном под
FastCGI.
------- Comment #21 From 2005-01-31 21:54:47 -------
Что характерно -- я очень серьёзно думаю переползать целиком под FastCGI.
Это у меня часть борьбы с уменьшением использования апача.

IMHO ветка 2.0 пошла куда-то не понятно куда. 1.3.* тормоз и недостаточно
удобна. Хостерам это, конечно, необходимость, но свои личные проекты уже
предпочитаю частично уводить из под апача.

После того как я увидел что установка простого реверс-прокси в разы уменьшает
потребление оперативки и процессора -- ну его нафиг. Посему FastCGI рулит :)
------- Comment #22 From 2005-02-01 11:06:24 -------
> После того как я увидел что установка простого реверс-прокси в разы уменьшает
> потребление оперативки и процессора -- ну его нафиг. Посему FastCGI рулит :)

Кстати, а реверс-прокси через mod_proxy или чем другим?
------- Comment #23 From 2005-02-01 11:39:57 -------
Именно.  Хотя про mod_accel где-то рядом висело, и bloodmary@ спрошала,
помнится...
------- Comment #24 From 2005-07-15 11:46:47 -------
Реверс-прокси лучше всего делать nginx. А на апаче нужен mod_realip (у нас
собран).