Php-fpm

Hallo,

mit Blick auf LiveConfig v2.7.0 und der Unterstützung von PHP-FPM möchte ich auf zwei wichtige Informationen hinweisen:

1. PHP-FPM unterstützt aufgrund seiner Architektur keine zend_extension-Anweisung pro Vertrag. Das ist keine Einschränkung von LiveConfig, sondern von PHP (siehe #73408).
   Erweiterungen, die via zend_extension geladen werden müssen (z.B. xdebug oder IonCube-Loader) müssen also in eine "echte" php.ini aufgenommen werden und sind somit global aktiv. Der sauberste Weg hierfür ist es, im jeweiligen "conf.d"-Verzeichnis (z.B. /etc/php/X.Y/fpm/conf.d, /opt/php-X.Y/etc/conf.d) eine Datei wie "ioncube.ini" anzulegen und darin die notwendige zend_extension-Anweisung einzutragen.
   LiveConfig erzeugt derzeit in der jeweiligen FPM-Pool-Konfigurationsdatei die "php_admin_value[zend_extension]"-Anweisung, die wird aber ignoriert (wir werden die künftig also gar nicht erst rausschreiben).
   Das bedeutet: wir empfehlen, individuelle zend_extension-Anweisungen aus der php.ini-Verwaltung von LiveConfig zu entfernen und die Erweiterungen statt dessen global (via conf.d/###.ini) zu aktivieren - somit gibt es keinen Unterschied in der PHP-Umgebung wenn man zwischen FastCGI und FPM umschaltet.
2. LiveConfig wird während des Upgrades auf v2.7.0-r5082 zwei weitere Einstellungen in die php.ini-Verwaltung aufnehmen: opcache.file_cache=%HOME%/tmp und opcache.lockfile_path=%HOME%/tmp. Das ist zwingend notwendig, um Dateien innerhalb des gemeinsamen Caches von Opcache sauber voneinander zu trennen.
   Architekturbedingt teilen sich nämlich alle PHP-FPM-Prozesse einen gemeinsamen Shared-Memory-Cache (also über Kunden/Vertragsgrenzen hinweg). Bis Anfang 2017 war das sogar ein akutes Sicherheitsrisiko (siehe ausführliche Diskussion bei #69090).
   Mit FastCGI (mod_fcgid) gab/gibt es dieses Problem nicht, das betrifft nur FPM.
   Die von uns bereitgestellten PHP-Pakete enthalten in der Datei conf.d/opcache.ini ab sofort zusätzlich die Anweisung "opcache.validate_permission=1" (zur Sicherheits nochmal der Hinweis: das ist nur für FPM relevant, beim bisherigen FastCGI macht das keinen Unterschied!)
   Fazit: die von LiveConfig erstellte Opcache-Konfiguration sorgt dafür, dass die Opcache-Dateien im jeweiligen Verzeichnis der einzelnen Kunden bleiben.
   Trotzdem ist Opcache ein latentes Sicherheitsrisiko in Shared-Hosting-Umgebungen, da die Sicherheit hier auf Anwendungsebene (PHP) und nicht auf Betriebssystemebene realisiert wird. Schafft es jemand, einen PHP-FPM-Prozess zu "kapern", hat er u.U. Zugriff auf den gemeinsamen Opcache.
   Wer etwas paranoider ist, sollte ggf. die Option opcache.file_cache_only aktivieren. Dann werden PHP-Scripte nicht im Shared Memory, sondern ausschließlich auf Dateiebene gecached und sind somit sauber isoliert.

Die aktuellen PHP-Versionen (gestern gab es ein neues Release) sind eben frisch compiliert und stehen in Kürze in unseren Repositories bereit.

Viele Grüße

-Klaus Keppler

Und noch ein kurzer Nachtrag: FPM bietet gegenüber Apache mod_fcgid kaum nennenswerte Vorteile, lediglich die Skalierbarkeit lässt sich etwas besser konfigurieren. Die Kommunikation zwischen den Prozessen (Apache <-> PHP) ist bei beiden Verfahren sogar identisch.
Lediglich mit NGINX macht FPM aufgrund des eigenen Prozessmanagers das Leben erheblich einfacher.

Wer sich etwas tiefer mit Control Panels, Shared Hosting und FPM beschäftigt wird feststellen, dass FPM und insbesondere Caching (nicht nur Opcache, sondern auch APC) hierbei ein ernstzunehmendes Problem darstellen. Es gibt Control Panels, denen das völlig Schnuppe ist - LiveConfig zählt nicht dazu.

Zitat von antondollmaier

Die Alternative dazu ist, für jeden Benutzer einen komplett eigenen PHP-FPM-Prozess (und nicht nur einen eigenen Pool) zu erstellen.

Das hatten wir uns natürlich auch schon überlegt
Mit systemd und "socket activation" bekommt man das sogar halbwegs sauber hin, ohne dass hunderte idle-Pools die Prozessliste zumüllen. Aber leider eben nur mit systemd. Und übersichtlicher wird das ganze dann auch nicht. Die Idee behalten wir mal im Hinterkopf, bei "normalem" Mass-Shared-Hosting schießt das eher über's Ziel hinaus.

Zitat von antondollmaier

Dort ergibt PHP-FPM aber IMHO - selbst mit "ondemand" - wenig Sinn.

ACK. Shared Hosting ist mit FastCGI und den vielen "exotischen" Ansprüchen wesentlich entspannter (der eine Kunde braucht IonCube, der andere ZendGuard, der dritte sonstwas - und die sind bisweilen zueinander inkompatibel...).
FPM macht insbesondere bei Projekt-Servern Sinn, da FPM einfach eleganter skaliert als FastCGI. Schneller ist es nicht (auch wenn das immer wieder hartnäckig behauptet wird).
Mass Shared Hosting mit NGINX macht auch keinen Sinn (die Performance, die ein NGINX bietet, kann ein Shared Webspace gar nicht vernünftig nutzen, und man benötigt irre viel "Tuning", um handelsübliche CMS zum Laufen zu bringen...). Aber ich glaube ich schweife ab...

Zitat von RB-Media-Group

ich habe eine Seite von FastCGI auf FPM umgestellt, nutze PHP 7.0.32 und habe ca. 250ms schnellere Reaktionszeiten laut Pingdom Test.

Wenn eine "Website" (PHP-Code) mal komplett gecached ist, gibt es technisch keinen Geschwindigkeitsunterschied zwischen FPM und FastCGI (die Kommunikation ist exakt die selbe, nur die Prozessverwaltung unterscheidet sich etwas).

APCu ist das eine - Opcache das andere... Bei FPM läuft das technisch so ab, dass ein PHP-Interpreter tatsächlich nur ein einziges Mal gestartet wird. Für alle Worker-Pools wird dieser dann geforked. Deshalb kann keine individuelle php.ini pro Pool verwendet werden, stattdessen muss man die gewünschten INI-Anweisungen via "php_admin_*"-Befehle in die Pool-Konfiguration schreiben (die werden quasi nach dem fork() nachträglich angewendet).
Für Shared-Hosting-Systeme bedeutet das: man kann nicht mehr einzelne Zend-Extensions nur für einzelne Webspaces laden, sondern diese müssen global registriert werden.

Bei FastCGI gibt es zwangsweise mindestens eine laufende PHP-Instanz pro Vertrag und pro PHP-Version. FPM ist hier flexibler und ermöglicht es, auch den "ersten" benötigten PHP-Interpreter nur bei Bedarf zu starten. Bei Shared-Hosting ermöglicht das somit (theoretisch) eine höhere Kundendichte pro Server, insbesondere wenn der Trend zu vielen verschiedenen PHP-Versionen gleichzeitig geht.

FPM ist also nicht pauschal "schneller" als FastCGI (die Kommunikation ist in beiden Fällen sogar exakt identisch), es kommt vielmehr auf den jeweiligen Anwendungsfall an.

Sehr gute Frage... ich habe auf Anhieb keinerlei Dokumentation dazu finden können.
Rein intuitiv würde ich sagen, dass dieses Limit nur pro Vertrag (= pro opcache.file_cache) Sinn macht - allerdings ist PHP einfach alles zuzutrauen...