1.2, ы (?), 04:28, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Я год назад пытался прейти на второго апача, выяснил что если в конфе апача указать расположение модулей Perl по пути отличном от системного с помощью PerlSwitches, апач сходил с ума. Выжирал всю память при вервом же запросе и падал. Надеюсь эту фигню пофиксили. Ждем-с в портах фри свежий mod_perl2, а так пока тусим на под старым добрым другом апачем 1.3 и первым mod_perl. :)
| |
|
2.4, alex_hunt (ok), 08:55, 09/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
Пользую PerlSwitches на апаче 2.2, работает как часы. Да и в рассылке такая бага не гуглится.
Может быть дело в чём-то другом?
| |
|
3.5, ы (?), 12:02, 09/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Может быть дело в чём-то другом?
Сейчас уже сложно сказать. Появится в портах 2.0.5 попробую повторить эксперимент. Сейчас уже и Perl другой юзаем 5.12. На тот момент был по-моему 5.10. В конфигурации особенного ничего нет, пара самописных модулей и все это под соусом HTML::Mason крутится.
А ругань была по типу: "Deep recursion on subroutine "Compress::Raw::Zlib::AUTOLOAD". Это я у себя в камментах на против опции PerlSwitches оставил на рабочей машине. Подробностей больше не осталось. При чем в наших модулях мы напрямую Zlib и не юзаем сами. Это либо в самом mod_perl касяк, либо в HTML::Mason где-то, либо еще в какой подключаемой либе используется.
Кстати, если не использовать данную опцию, а кинуть модули по системному пути, то все работало. Но на тот момент такой вариант не подошел.
| |
|
|
1.6, Аноним (-), 17:37, 09/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не знаю уж... разве еще не все перешли на FCGI или Plack? Или что-то типа HTTP::Server?
| |
|
|
|
4.10, ы (?), 19:43, 10/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
Очень смешно, mod_perl для того и нужен, чтобы все держать в памяти, чтобы максимуму быстро обслужить юзверя, не тратя время на подгрузку и компиляцию либ и прочую ерунду.
| |
|
5.11, Name (?), 01:55, 12/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Очень смешно, mod_perl для того и нужен, чтобы все держать в памяти,
> чтобы максимуму быстро обслужить юзверя, не тратя время на подгрузку и
> компиляцию либ и прочую ерунду.
Однако он медленнее, чем FastCgi/Nginx.
| |
|
6.12, zero (??), 03:10, 12/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>Однако он медленнее, чем FastCgi/Ngnix.
В общем-то вопрос скорее религиозный и зависим от архитектуры веб-приложения, чем проблема в скорости. Ну и не забываем, что у mod_perl есть такие фичи, которых у FastCGI просто не может быть из-за разных подходов в работе. mod_perl позволяет лазить в самые кишки веб-сервера и вытворять всякие полезности на этапе обработки запроса. FastCGI это фактически классический CGI, но быстрее обычного.
http://kiev.pm.org/?q=node/424 - тут разжевано.
| |
|
|
|
|
|
|