apache2-worker + cgi-perl против apache2-prefork + mod_perl - что быстрее? что требует меньше ресурсов?
Хия. Я использую Gentoo Linux. кажется, что я не могу установить / установить mod_perl с поточным apache2, поэтому я хотел бы знать, каковы плюсы и минусы использования рабочего модуля apache2 с cgi-perl и использования модуля prefork apache2 с mod_perl
что быстрее? что требует меньше ресурсов? с точки зрения безопасности, есть ли разница?
Спасибо!
4 ответа
В Linux используйте prefork apache w/ mod_perl. Threaded MPM - это огромный выигрыш для пользователей Win32, где создание процессов стоит дорого. На linux fork() довольно дешевый вызов. Однако разработчики Mod_perl2 приложили немало усилий, чтобы заставить mod_perl2 работать с потоками apache2 +, но модель потоков в perl немного загружает память.
Мы разрабатываем большое приложение mod_perl, и если бы нам пришлось его воссоздавать сегодня, я бы, вероятно, порекомендовал бы одну из различных платформ и использовал бы FastCGI или PSGI. Использование FCGI или фрейма с собственными возможностями PSGI/FCGI позволяет вам выбирать интерфейсы (nginx, lighttpd, apache2). Вы можете изменить свое приложение и уменьшить его привилегии (ему нужен только сокет для общения с вашим интерфейсом). Если вы заставляете ваше приложение использовать mod_perl2, вы в значительной степени женаты на Apache2.
Modperl является идеальным адаптером для Catalyst, точно так же, как Modpython и Modwsgi для Django, а modphp для Cakephp, тогда как Modruby обсуждается как лучше или хуже, чем cgi, fcgi и (Modrails/Modpassenger/Modlocomobil) для Rails особенно при использовании многопоточного режима (но в качестве альтернативы есть Modrake и прокси-сервер приложений Mongrel). Чтобы избежать недостатков и получить только преимущества, всегда используйте раздвоенный режим. Я использую ссылки только на mvc из других языков программирования, которые вдохновлены рельсами: т.е. Catalyst, Django, Cakephp и Rails.
На мой взгляд, лучше всего использовать многопоточный режим mpm-itk, за которым следует многопоточный режим-события mpm, затем одиночный раздвоенный режим mpm-prefork и, наконец, однопоточный режим 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, но, конечно, даже в случае всех трех адаптеров разветвленный режим работает быстрее, более универсален и бесконфликтен, чем многопоточный режим. И одно можно сказать наверняка: все эти адаптеры предназначены для работы быстрее, чем cgi, и, возможно, так же быстро, как fcgi (fastcgi).
Я использую режим itk (multi-разветвленный), даже если это означает, что мне не хватает некоторых программ, для которых требуется режим prefork (однокорневой разветвления).
Я всегда предпочитал itk-режим в Ubuntu и никогда не выбирал установку приложений, для которых в качестве предварительного условия требуется режим prefork. Некоторые дистрибутивы, такие как Sabayon, который является разновидностью Gentoo, по умолчанию устанавливают apache2 в рабочий режим. Но это мы всегда можем изменить, отредактировав файл конфигурации системы apache и раскомментировав строки, содержащие itk (и закомментируйте строки для worker), после чего перекомпилируйте и перезапустите apache2. Итак, все, что относится к Sabayon, должно быть в силе и для Gentoo. Sabayon и Gentoo устанавливают все программное обеспечение, зависящее от prefork или работника, но при их настройке должны работать только те, чья зависимость выполняется системой.
Очень сильно пострадали некоторые из основанных на php фреймворков (необходимых для систем управления контентом), которые не запускаются. Единственный php-фреймворк, который может работать в режиме itk, event (и, возможно, работника), это торт-php, который, к сожалению, очень мало используется. Я думаю, что даже более известная структура орды (php) также должна работать.
Еще одним доказательством того, что потоки хуже, чем вилки, является рассмотрение количества или конфликтов, которые два или более адаптера веб-сервера имеют по отношению друг к другу и системе, как мы видим в окнах.
В случае окон, apache2 конфигурируется с рабочим режимом, так как режимы prefork и itk невозможны, но режим события должен быть очень возможным. Таким образом, переключение в режим событий Apache2 (многопоточный) должно решить большинство проблем. Но apache2 является очень гибким и настраиваемым для modperl (и, следовательно, perl-катализатор 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 не должна присутствовать - в противном случае иногда оболочка windowsxp по умолчанию может вылетать (вы все равно можете восстановить, используя windowsxp с альтернативным оболочки, такие как реагирующая оболочка, emerge-desktop, sharp-enviro, bblean-blackbox и т. д. с альтернативными файловыми менеджерами, такими как ros-explorer, cubic-explorer, ultra-explorer и т. д. - при условии, что любой пользователь не против адаптации и используя ту же ОС с по-разному выглядящим десктоп-оболочкой и файловым менеджером).
В Windows, таким образом, modrails конфликтуют с modphp (до тех пор, пока не станет доступен стабильный modruby), и что windows-desktop-shell на основе asp (среда объектной модели сети Windows) может содержать только по одному за раз, тогда как альтернативные оболочки, написанные в кодовых блоках (actos и emerge-desktop) не аварийно завершают работу, в то время как те, что написаны на delphi (sharp-enviro), частично аварийно завершают работу, но ремейк sharp-enviro с использованием lazarus не должен аварийно завершаться.
Таким образом, одна из причин, по которой веб-технология Linux гораздо шире и все же успешна, связана с преимуществами раздвоенного режима по сравнению с многопоточным. Веб-технология Windows по-прежнему вращается в целом по сравнению с меньшим количеством игроков и некоторыми технологиями с открытым исходным кодом после выполнения тяжелой работы.
ИМХО, prefork+mod_per будет намного быстрее, но запрос в списке рассылки mod_perl даст вам более точный ответ
Просто дополнительная информация, мы просто сбросили mod_perl на Win32 и переключились на PSGI с помощью Plack. Для CGI::Application существует слой совместимости, который очень хорошо работает для нас. Катализатор переключается / также переключился на PSGI.