ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Build DSO mod_perl | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sir Raorn <raorn> | ||||||
| Component: | apache | Assignee: | Michael Shigorin <mike> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus | ||||||
| Severity: | enhancement | ||||||||
| Priority: | P2 | CC: | at, bloodmary, cas, crux, ender, lakostis, ldv, mike, mithraen, qa_viy, rider, shaba, solo, tosick, viy | ||||||
| Version: | unstable | ||||||||
| Hardware: | all | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
|
Description
Sir Raorn
2004-10-01 08:30:08 MSD
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 (у нас собран). |
