Привет. Я использую Gentoo Linux. Похоже, что я не могу установить mod_perl с потоковым Apache2, поэтому я хотел бы узнать, каковы плюсы и минусы использования рабочего модуля Apache2 с cgi-perl и использования prefork-модуля Apache2 с mod_perl.
что быстрее? что требует меньше ресурсов? с точки зрения безопасности, есть ли разница?
Спасибо!
решение1
В Linux используйте prefork apache с mod_perl. Потоковый MPM — это огромное преимущество для пользователей Win32, где создание процесса стоит дорого. В Linux fork() — довольно дешевый вызов. Однако разработчики Mod_perl2 приложили немало усилий, чтобы заставить mod_perl2 работать с apache2 + потоками, но модель потоков в perl немного потребляет память.
Мы разрабатываем большое приложение mod_perl, и если бы нам пришлось воссоздавать его сегодня, я бы, вероятно, рекомендовал один из различных фреймворков и использовал FastCGI илиПСГИ. Использование FCGI или фреймворка с собственными возможностями PSGI/FCGI позволяет вам выбирать между фронтендами (nginx, lighttpd, apache2). Вы можете chrootить свое приложение и понизить его привилегии (ему нужен только сокет для взаимодействия с вашим фронтендом). Если вы заставите свое приложение использовать mod_perl2, вы практически женаты на Apache2.
решение2
IMHO, prefork+mod_per будет намного быстрее, но запрос в списке рассылки mod_perl даст вам более точный ответ.
решение3
Modperl — идеальный адаптер для Catalyst, точно так же, как Modpython и Modwsgi для Django, а modphp для Cakephp, в то время как Modruby обсуждается как лучший или худший, чем cgi, fcgi и (Modrails/Modpassenger/Modlocomotive) для Rails, особенно при использовании потокового режима (но есть Modrake и проксирующий Mongrel app-server в качестве альтернативы). Чтобы избежать недостатков и получить только преимущества, всегда используйте разветвленный режим. Я ссылаюсь только на mvc других языков программирования, которые вдохновлены rails: то есть Catalyst, Django, Cakephp и Rails.
По моему мнению, наилучшим является многопоточный режим mpm-itk-mode, за ним следует многопоточный режим mpm-event-mode, затем идет однопоточный режим mpm-prefork-mode, а затем, наконец, однопоточный режим mpm-worker-mode.
Я обнаружил, что для некоторых языков программирования соответствующие им адаптеры apache2, такие как mod-php и mod-tcl, работают только в режиме prefork и даже не работают в режиме itk, в то время как mod-ruby все еще есть только в linux-apache2 и еще не появился в windows-apache2.
Но, к счастью, mode-perl, mod-python и mod-ruby достаточно универсальны и могут работать во всех четырех режимах — libapache-mpm-worker, libapache-mpm-prefork, libapache-mpm-event и libapache-mpm-itk. Это хорошие новости для пользователей perl, python и ruby, но, конечно, даже в случае всех трех адаптеров режим fork быстрее, более универсален и бесконфликтен, чем потоковый режим. И одно можно сказать наверняка: все эти адаптеры разработаны для работы быстрее, чем cgi, и, возможно, так же быстро, как fcgi (fastcgi).
Я использую режим itk (multifork), даже если это означает, что мне будет не хватать некоторых программ, требующих режима prefork (single fork).
Я всегда предпочитал itk-mode в Ubuntu и никогда не выбирал установку приложений, требующих prefork-mode в качестве предварительного условия. Некоторые дистрибутивы, такие как Sabayon, который является разновидностью Gentoo, устанавливают apache2 в рабочем режиме по умолчанию. Но это мы всегда можем изменить, отредактировав файл конфигурации системы apache и раскомментировав строки, содержащиеитк(и прокомментируйте строки длярабочий) с последующей перекомпиляцией и перезапуском apache2. Таким образом, все, что применимо к Sabayon, должно быть применимо и к Gentoo. Sabayon и Gentoo устанавливают все prefork-зависимые или worker-зависимые программы, но при их настройке должны запускаться только те, зависимость которых удовлетворяется системой.
Сильно пострадали некоторые фреймворки на основе PHP (необходимые для систем управления контентом), которые не запускаются. Единственный фреймворк PHP, который может работать в режиме itk, event (и, возможно, worker), — это cake-php, который, к сожалению, используют очень немногие. Я думаю, что даже более известный фреймворк horde (php) также должен работать.
Еще одним доказательством того, что потоки хуже ветвлений, является анализ количества конфликтов, которые два или более адаптеров веб-серверов имеют друг с другом и с системой, как мы видим в Windows.
В случае Windows apache2 настраивается с помощью worker-mode, поскольку prefork и itk режимы невозможны, но event-mode должен быть вполне возможен. Таким образом, переключение в event-mode apache2 (многопоточный) должно решить большинство проблем. Но apache2 очень гибкий и настраиваемый для modperl (и, следовательно, perl-catalyst mvc), modpython (и, следовательно, django mvc), а вот windows-modruby пока не стабилен, его эквивалент, известный как modpassenger (modpassenger -- linux, modrails -- windows, locomotive -- macosx), существует в abyss-webserver или lighttpd-webserver (и, следовательно, rails mvc).
Меры предосторожности: если система — Windows, то перед установкой MVC Perl/Python/Ruby/PHP/Tcl убедитесь, что все настроено только с одним единственным веб-сервером — либо apache2, либо lighttpd, либо, может быть, cherokee. Если вы собираетесь использовать rails с abyss, modrails, то убедитесь, что конфигурация drupal/jhoomla с wamp, modphp не должна присутствовать — в противном случае иногда может произойти сбой оболочки Windows XP по умолчанию (вы все равно можете восстановиться, используя Windows XP с альтернативными оболочками, такими как reactos-shell, emerge-desktop, sharp-enviro, bblean-blackbox и т. д., с альтернативными файловыми менеджерами, такими как ros-explorer, cubic-explorer, ultra-explorer и т. д. — при условии, что пользователь не против адаптировать и использовать ту же ОС с по-другому выглядящей оболочкой рабочего стола и файловым менеджером).
В Windows modrails конфликтуют с modphp (пока не станет доступна стабильная версия modruby), а основанная на asp оболочка windows-desktop-shell (среда сетевой объектной модели Windows) может содержать только одну оболочку за раз, тогда как альтернативные оболочки, написанные на codeblocks (reactos и emerge-desktop), не дают сбоев, а написанные на delphi (sharp-enviro) дают частичные сбои, но ремейк sharp-enviro на Lazarus не должен давать сбоев.
Таким образом, одна из причин, по которой веб-технология Linux гораздо более разнообразна и при этом успешна, заключается в преимуществах разветвленного режима над потоковым режимом. Веб-технология Windows по-прежнему вращается в целом вокруг меньшего числа игроков и нескольких технологий с открытым исходным кодом после выполнения большой и тяжелой работы.
решение4
Просто немного дополнительной информации, мы только что сбросили mod_perl на Win32 и перешли на PSGI с помощью Plack. Есть слой совместимости для CGI::Application, который работает у нас очень хорошо. Catalyst также переключается/перешел на PSGI.