Apache 2.4, ISPConfig 3 & PHP-FPM

[JeGr]

Hi,

ich habe das neue Tutorial von Falko bezüglich ISPC3 & Ubuntu 14.04LTS gelesen, bei dem ja bereits Apache 2.4 und PHP 5.5 zum Einsatz kommen.

Meines Erachtens ist aber der bevorzugte bzw. empfohlene Weg (von Seitens PHP wie auch Apache), PHP jetzt via PHP-FPM & mod_proxy_fcgi einzubinden.

Durch die Installation und um den Usern die Möglichkeit zu geben auch alles auswählen zu können, wird aber nun überall in Verbindung mit ISPC3 zum einen der langsamere Prefork Worker statt des neuen Event Workers sowie mod-php + suphp + mod_fastcgi etc. etc. installiert.

a) Läuft ISPC3 (Backend) auch mit PHP-FPM + Event Worker + mod_proxy_fcgi sauber? Da waren in der Vergangenheit immer Statements von Till oder Falko aufgekommen, dass es bei Umstellung des Workers im Backend evtl. zu Problemen kommen könnte

b) Würde es - so a) gegeben ist - dann nicht Sinn machen, den ganzen Wahnsinn an Varianten (suphp, mod_cgi, fastcgi, suexec, whatever) zu minimieren und den Weg mit Event Worker, FPM und mod_proxy_fcgi zu gehen?

Da mit PHP 5.5 und Apache 2.4 eh einige Projekte und Applikationen überarbeitet werden müssen, habe ich persönlich bislang noch keines gesehen, welches mit der Kombo läuft, aber dann Probleme mit Eventworker oder PHP-FPM hat.

Bislang war - zumindest mein Eindruck - das Feedback von Apache und Co., dass so PHP zum einen schneller (am Schnellsten?) läuft (in eingen Tests auch besser als mod_php) und man dazu keinen Streß wie bei Suexec oder SuPHP betreiben muss, da durch die FPM Pools User/Gruppenzuordnung kein Problem mehr sind.

Damit würde m.E. für ein Shared Hosting gute/beste Performance auf gute Abschottung treffen. Vor allem würde es aber die Einstellung an der Stelle minimieren, bei der mich immer wieder diverse Reseller oder Kunden fragen "welche PHP Art muss ich da einstellen, dass das die 'beste' ist?". Zumal SuPHP sehr langsam (und m.E. veraltet), SuExec umständlich und reines FastCGI IMHO unnötig ist. Und durch die ProxyPass Konfiguration sollten sich auch die vorhandenen Probleme mit FPM vs. FastCGI lösen lassen (Aliasdomains Umleitung bei FastCGI u.ä.).

Grüße
Jens

 

[Till]

a) Das Backend läuft mit php-fcgi und nicht mehr mit mod_php wie früher, es sollte also generell funktionieren, solange du nicht mod_fcgi und php-fcgi entfernst.

b) Dann würden sich bei uns zehntausende User beschweren, wenn auf einmal Ihre seiten nicht mehr gehen weil wir den support für z.B. suphp einstellen und die seiten nach einem ispconfig update offline sind. Es nutzen z.B. immer noch viele User Centos 5.10, das hat php 5.1.

Generell halte ich es für gut dass man die PHP Modi irgendwann reduziert, das ist aber halt nicht so einfach ohne die altinstallationen zu beeinflussen und bei um die 40 tausend downloads im Monat sind das halt ziemlich viele server, die das betrifft.

Damit würde m.E. für ein Shared Hosting gute/beste Performance auf gute Abschottung treffen. Vor allem würde es aber die Einstellung an der Stelle minimieren, bei der mich immer wieder diverse Reseller oder Kunden fragen "welche PHP Art muss ich da einstellen, dass das die 'beste' ist?". Zumal SuPHP sehr langsam (und m.E. veraltet), SuExec umständlich und reines FastCGI IMHO unnötig ist. Und durch die ProxyPass Konfiguration sollten sich auch die vorhandenen Probleme mit FPM vs. FastCGI lösen lassen (Aliasdomains Umleitung bei FastCGI u.ä.).

Das sollte seit ISPConfig 3.0.4 kein problem mehr sein, denn Du kannst die sichtbaren php modi auf Reselelr und auch Kundenlevel einschränken. Wenn Du nur php-fpm anbieten willst, ist das also kein problem. dein Kunde oder Reseller sieht dann nur php-fpm, wenn Du es so für ihn einstellst.

Reines fastcgi wird noch sehr häufig verwendet und ist auch notwendig, da php-fpm in oftmals benötigten alten php Versionen garnicht zur Verfügung steht. Viele Agenturen und Firmen schlagen sich mit Webseiten und CMS rum, die nicht unter einer neuen PHP Version laufen oder mit einem exotischen encoder verschlüsselt sind und daher z.B. auf php 5.1 oder 5.2 angewiesen sind.

 

[JeGr]

Hallo Till,

natürlich gäbe es dann Probleme, wenn man die Option bei einem Update direkt entfernt, ohne bspw. einen Weg der Konvertierung festzulegen. Aber SuPHP bspw. sollte sich ja mit einem FPM Pool noch am Leichtesten abdecken lassen, da hier auch mit User/Gruppe alles soweit schon richtig verknotet ist. Es müsste dann eben die Konfiguration angepasst werden, keine Frage. Auch kein leichter Punkt, das verstehe ich. Und ich denke da auch eher nicht an Alt-Server, sondern an frische/neue Installation.

Ich kenne auch viele Downloads von ISPC und sehe, dass sich viele nach den sehr gut ausgeführten Howtos richten. Hier ist aber dann nicht bekannt, was technisch dahinter steckt. Deshalb die Frage ob es überhaupt schon sauber funktionieren würde. Und dann wäre es ja durchaus eine Überlegung, ob - sofern möglich - eine Neuinstallation von ISPC3 denkbar ist, die schon direkt nur noch bspw. FPM und ggf. vllt. noch fastcgi mitbringt (sollte mit event worker laufen wenn ich nicht irre).

Das Problem mit alten Versionen haben wir leider auch, allerdings ist immerhin mit IonCube oder Zend es möglich bis auf PHP 5.4 zu kommen (mit Ioncube auch 5.5+, nur Zend ist da weit hinter der Zeit :/ ) und so es kein exotisches CMS ist, bekommt man es häufig auch noch mit 5.3 ans Laufen, womit es dann zumindest mit FPM oder FastCGI laufen sollte.

Die Frage ist dann aber auch ob ISPC3 gerade schon die Konfiguration von mod_proxy_fcgi überhaupt unterstützt (ProxyPass Regeln etc.) oder ob es noch komplett auf die Arbeitsweise von Prefork ausgelegt ist?
Und die zweite Frage: ob es tatsächlich möglich wäre eine Neuinstallation zu bauen, in der bspw. nur noch fastcgi und php-fpm laufen.

Da wir z.B. noch einen alten ISPC2 und einen älteren ISPC3 Server laufen haben, für die wir die Kunden eh portieren müssen, wäre es spannend zu wissen ob man so einen schnellen, sauberen neuen ISPC3 Cluster bauen könnte, der dann auch mal State of the Art läuft und nicht mit Kompromissen. Mir wäre ja auch LEMP recht, aber einige Anwendungen wollen eben unbedingt mit exotischen Apache Konfigs laufen und streiken mit NGINX (oder man verliert den Support des Hersteller *augenroll*)

Wenn wir PHP 5.3+ als Maßstab anlegen, habe ich bislang kaum etwas gefunden, bei dem FPM streiken würde. Und mit phpbrew und co. lassen sich dann auch 3-4 PHP Varianten als FPM gut verwalten.

Auf Meinung gespannt und Grüße