Hallo. Ich verwende Gentoo Linux. Es scheint, dass ich mod_perl mit einem Threaded Apache2 nicht emergen/installieren kann, daher würde ich gerne wissen, was die Vor- und Nachteile der Verwendung des Worker-Moduls von Apache2 mit CGI-Perl und der Verwendung des Prefork-Moduls von Apache2 mit mod_perl sind.
was ist schneller? was verbraucht weniger Ressourcen? Gibt es in puncto Sicherheit einen Unterschied?
Danke!
Antwort1
Verwenden Sie unter Linux prefork apache mit mod_perl. Das Threaded MPM ist ein großer Vorteil für Win32-Benutzer, bei denen die Prozesserstellung teuer ist. Unter Linux ist fork() ein ziemlich billiger Aufruf. Die Entwickler von Mod_perl2 haben sich jedoch große Mühe gegeben, mod_perl2 mit Apache2 + Threads zum Laufen zu bringen, aber das Thread-Modell in Perl ist etwas speicherintensiv.
Wir entwickeln eine große mod_perl-Anwendung und wenn wir sie heute neu erstellen müssten, würde ich wahrscheinlich eines der verschiedenen Frameworks empfehlen und FastCGI verwenden oderPSGI. Wenn Sie FCGI oder ein Framework mit nativen PSGI/FCGI-Funktionen verwenden, haben Sie die Wahl zwischen Frontends (nginx, lighttpd, apache2). Sie können Ihre App chrooten und ihre Berechtigungen verringern (sie benötigt nur einen Socket, um mit Ihrem Frontend zu kommunizieren). Wenn Sie Ihre App mod_perl2 verwenden lassen, sind Sie praktisch an Apache2 gebunden.
Antwort2
Meiner Meinung nach wäre prefork+mod_per viel schneller, aber eine Frage in der mod_perl-Mailingliste würde Ihnen eine genauere Antwort geben
Antwort3
Modperl ist der perfekte Adapter für Catalyst, genau wie Modpython und Modwsgi beide für Django und Modphp für Cakephp sind, während Modruby als besser oder schlechter als CGI, FCGI und (Modrails/Modpassenger/Modlocomotive) für Rails diskutiert wird, insbesondere bei Verwendung des Thread-Modus (es gibt jedoch Modrake und den Proxy-App-Server Mongrel als Alternativen). Um die Nachteile zu vermeiden und nur Vorteile zu erzielen, verwenden Sie immer den Fork-Modus. Ich beziehe mich nur auf MVCs anderer Programmiersprachen, die von Rails inspiriert sind: d. h. Catalyst, Django, Cakephp und Rails.
Meiner Meinung nach ist der mehrgegabelte MPM-ITK-Modus am besten, gefolgt vom mehrthreadigen MPM-Event-Modus, dann kommt der einfachgegabelte MPM-Prefork-Modus und zuletzt der einfachthreadige MPM-Worker-Modus.
Ich habe festgestellt, dass die jeweiligen Apache2-Adapter, beispielsweise mod-php und mod-tcl, für einige Programmiersprachen nur im Prefork-Modus und nicht einmal im ITK-Modus laufen, während mod-ruby immer noch nur in Linux-Apache2 verfügbar ist und es noch nicht in Windows-Apache2 geschafft hat.
Aber glücklicherweise sind mode-perl, mod-python und mod-ruby vielseitiger genug und können in allen vier Modi ausgeführt werden – libapache-mpm-worker-Modus, libapache-mpm-prefork-Modus, libapache-mpm-event-Modus und libapache-mpm-itk-Modus. Das sind gute Neuigkeiten für Perl-, Python- und Ruby-Benutzer, aber natürlich ist der gegabelte Modus auch bei allen drei Adaptern schneller, vielseitiger und konfliktfreier als der Threaded-Modus. Und eines ist sicher: Alle diese Adapter sind so konzipiert, dass sie schneller als cgi und wohl genauso schnell wie fcgi (fastcgi) ausgeführt werden.
Ich verwende den ITK-Modus (Multiforked), auch wenn das bedeutet, dass mir einige Software fehlt, die den Prefork-Modus (Single Forked) erfordert.
Ich habe in Ubuntu immer den itk-Modus bevorzugt und mich nie dafür entschieden, Anwendungen zu installieren, die den Prefork-Modus als Voraussetzung benötigen. Einige Distributionen wie Sabayon, eine Gentoo-Variante, installieren Apache2 standardmäßig im Worker-Modus. Dies können wir jedoch jederzeit ändern, indem wir die Apache-Systemkonfigurationsdatei bearbeiten und die Zeilen mit folgendem Inhalt auskommentieren:esk(und kommentieren Sie die Zeilen fürArbeiter), gefolgt von einer Neukompilierung und einem Neustart von Apache2. Was also für Sabayon gilt, sollte auch für Gentoo gelten. Sabayon und Gentoo installieren alle Prefork- oder Worker-abhängigen Softwareprogramme, aber während der Konfiguration sollten nur diejenigen ausgeführt werden, deren Abhängigkeit vom System erfüllt wird.
Besonders betroffen sind einige der PHP-basierten Frameworks (erforderlich für Content-Management-Systeme), die nicht ausgeführt werden können. Das einzige PHP-Framework, das im ITK-, Event- (und vielleicht Worker-)Modus ausgeführt werden kann, ist Cake-PHP, das leider nur sehr wenige verwenden. Ich denke, dass auch das bekanntere Horde-Framework (PHP) funktionieren sollte.
Ein weiterer Beweis dafür, dass Threads schlimmer sind als Forks, ist die Betrachtung der Anzahl der Konflikte, die zwei oder mehr Webserver-Adapter untereinander und mit dem System haben, wie wir es bei Windows sehen.
Unter Windows konfiguriert sich Apache2 im Worker-Modus, da die Modi Prefork und ITK nicht möglich sind, der Event-Modus jedoch durchaus möglich sein sollte. Ein Wechsel in den Event-Modus (Multithread) von Apache2 sollte also die meisten Probleme lösen. Apache2 ist jedoch sehr flexibel und anpassbar für Modperl (und damit Perl-Catalyst MVC), Modpython (und damit Django MVC), aber Windows-Modruby ist noch nicht stabil, sein Äquivalent bekannt als Modpassenger (Modpassenger – Linux, Modrails – Windows, Locomotive – MacOSX) existiert in Abyss-Webserver oder Lighttpd-Webserver (und damit Rails MVC).
Vorsichtsmaßnahme: Wenn das System Windows ist, stellen Sie vor der Installation der MVCs von Perl/Python/Ruby/PHP/Tcl sicher, dass alles nur mit einem einzigen Webserver konfiguriert ist – entweder Apache2 oder Lighttpd oder vielleicht Cherokee. Wenn Sie Rails mit Abyss oder Modrails verwenden möchten, stellen Sie sicher, dass die Drupal/Jhoomla-Konfiguration mit Wamp oder Modphp nicht vorhanden ist – andernfalls kann die Standard-Windows-Shell von Windows XP manchmal abstürzen (Sie können es immer noch wiederherstellen, indem Sie Windows XP mit alternativen Shells wie Reactos-Shell, Emerge-Desktop, Sharp-Enviro, Bblean-Blackbox usw. mit alternativen Dateimanagern wie Ros-Explorer, Cubic-Explorer, Ultra-Explorer usw. verwenden – vorausgesetzt, der Benutzer hat nichts dagegen, dasselbe Betriebssystem mit einer anders aussehenden Desktop-Shell und einem anders aussehenden Dateimanager anzupassen und zu verwenden).
Unter Windows stehen Modrails daher in Konflikt mit Modphp (bis ein stabiles Modruby verfügbar wird) und die ASP-basierte Windows-Desktop-Shell (Windows Network Object Model Environment) kann immer nur eine gleichzeitig enthalten, während die in Codeblocks geschriebenen alternativen Shells (Reactos und Emerge-Desktop) nicht abstürzen und die in Delphi geschriebenen (Sharp-Enviro) teilweise abstürzen, ein Lazarus-Remake von Sharp-Enviro jedoch nicht abstürzen sollte.
Einer der Gründe, warum die Linux-Webtechnologie so vielfältig und dennoch erfolgreich ist, sind die Vorteile des Fork-Modus gegenüber dem Thread-Modus. Die Windows-Webtechnologie wird nach wie vor im Großen und Ganzen von weniger Akteuren und einigen wenigen Open-Source-Technologien betrieben, obwohl viel harte Arbeit geleistet wurde.
Antwort4
Nur ein paar zusätzliche Informationen: Wir haben gerade mod_perl auf Win32 deinstalliert und sind mit Plack auf PSGI umgestiegen. Es gibt eine Kompatibilitätsschicht für CGI::Application, die bei uns sehr gut funktioniert. Catalyst wechselt/ist ebenfalls auf PSGI umgestiegen.