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