ManagedServer PHP fcgi oder Modul?

  • Thread starter Thread starter MrFreeze
  • Start date Start date

M

MrFreeze

Guest
Hallo,

habe überall gelesen das php fcgi vorteile hätte gegenüber php als Modul einzubinden.
Mein Hoster schreibt mir nun

Ihr hattet angeregt von mod_php auf PHP als FastCGI zu wechseln. Dieses unterscheidet sich darin, dass die PHP-Prozesse nicht mehr im Webserver direkt ausgeführt werden sondern in einen externen Prozess ausgelagert werden. Dieses erhöht die Ladezeiten, da zusätzlich die Anfrage an einen Prozess weitergegeben wird und nicht mehr vom Webserver beantwortet wird. Zudem ist deutlich mehr Arbeitsspeicher erforderlich, da der komplette PHP-Interpreter für jede Anfrage separat in den Arbeitsspeicher geladen wird. Vorteilhaft ist, dass die Prozesse mit anderen Benutzerrechten ausgeführt werden können. Dies ist sinnvoll wenn man mehrere unterschiedliche Webseiten auf einem System betreibt. Auf einem System mit nur einer Webseite bringt dies jedoch keinen Vorteil. Unter der URL https://www.chriswiegman.com/2011/10/fastcgi-vs-suphp-vs-cgi-vs-mod_php-dso/ - Punkt "So which is best?" findest du noch mal eine unabhängige Zusammenfassung zu dem Thema. Dort wird FastCGI gegenüber mod_
php ebenfalls die gleiche Performance, jedoch viel mehr Arbeitsspeicherkonsum bescheinigt.

Dies kann ich, was ich alles gelesen habe darüber nicht verstehen.

Was meint ihr zu seiner Erklärung. Klar es läuft nur eine Webseite auf dem Server. Dafür aber eine sehr grosse (forum)
 
Wenn es nur eine Seite ist, wäre es deutlich empfehlenswert weder auf das Eine noch das Andere zu setzen sondern PHP-FPM - quasi der Fastcgi-Nachfolger.
FPM verschlankt den Apache Server deutlich (der muss ja schliesslich auch noch andere Sachen tun als nur PHP) ohne Leistung ein zu bußen; dank entsprechender Optimierung ist er sogar schneller als mod_php.

Bei Server mit vielen Requests und mehreren Benutzer ist allerdings weder fastcgi noch fpm das Goldene vom Ei. Das Eine braucht viel mehr Leistung, das Andere braucht deutlich zuviel Ram - hier bleibt als beste Lösung mod_php. Allerdings ist dann der Einsatz von ITK als Apache2-MPM zwingend notwendig um die Sicherheit weiterhin gewährleisten zu können und keine Einbußen bei der Benutzerverwaltung und Rechteabsicherung hinnehmen zu müssen.

. Dieses erhöht die Ladezeiten, da zusätzlich die Anfrage an einen Prozess weitergegeben wird und nicht mehr vom Webserver beantwortet wird. Z
Die Zeit einer Socket-Verbindung kann mehr oder weniger vernachlässigt werden. Nur schon das Ausgeben von time() in PHP ist um Größenordnungen langsamer als die reine UNIX-Socket Verbindung zum PHP backend.
 
Wenn es nur eine Seite ist, wäre es deutlich empfehlenswert weder auf das Eine noch das Andere zu setzen sondern PHP-FPM - quasi der Fastcgi-Nachfolger.
FPM verschlankt den Apache Server deutlich (der muss ja schliesslich auch noch andere Sachen tun als nur PHP) ohne Leistung ein zu bußen; dank entsprechender Optimierung ist er sogar schneller als mod_php.

Nicht nur bei einer Seite. PHP-FPM kann man durchaus auch für deutlich mehr Seiten einsetzen. Als Nachfolger von FCGI würde ich es aber nicht betrachten, eher als Alternative. Beides hat Vor- und Nachteile.

Wir haben aktuell PHP-FCGI auf unseren Webservern im Einsatz. 100-200 Webseiten pro Server sind eigentlich kein Problem. Natürlich entstehen deutlich mehr Systemprozesse als bei mod_php, allerdings stehen die Prozesse mehreren Anfragen zur Verfügung und werden nicht pro Anfrage neu erstellt. Der Overhead hält sich daher in Grenzen.
Ein großer Vorteil von FCGI ist z.B. das bessere Caching. Du kannst aber generell alle Performancevorteile unter http://www.fastcgi.com/devkit/doc/fcgi-perf.htm sauber aufgelistet finden.
 
Nicht nur bei einer Seite. PHP-FPM kann man durchaus auch für deutlich mehr Seiten einsetzen.
Das war hier eher darauf bezogen dass der TE nur eine Seite auf dem Server liegen hat - zumindest laut dem Zitat.

Wir haben aktuell PHP-FCGI auf unseren Webservern im Einsatz. 100-200 Webseiten pro Server sind eigentlich kein Problem.
Hier sei aber gesagt dass eine solch geringe Anzahl an vHosts nicht weit von "eine Webseite" weg ist und generell für high-traffic Seiten zum Einsatz kommt - zumindest wenn mit den üblichen Anzahlen an vhosts pro Webhosting-Server verglichen.
 

Back
Top