mod_fcgid oder mod_php5

[GodHunter]

Hi,

ich wollt mal in die Runde horchen was Ihr nutzt um PHP Scripte auszuführen.
Also ich setze FastCGI ein da ich einerseits der Meinung bin das PHP Scripte schneller geladen werden als unter mod_php5 und es in Verbindung mit SuExec sicherer ist.

Allerdings soll es ja in Verbindung mit vielen vHosts stark am Arbeitsspeicher zehren und somit in die Knie gezwungen werden, außerdem schwören immer noch viele auf mod_php5 ... warum?

Also vielleicht kann mir auch jemand erklären warum mod_php5 immer noch interessant (interessanter) ist?!

€dt: Die Frage bezieht sich auf mehrere User / vHosts

 

[MTLServices]

Hallo,

außerdem schwören immer noch viele auf mod_php5 ... warum?

Weil viele die Grundkonfiguration des Server-Images nicht verändern wollen/können und meist mod_php als Standard installiert ist. Des Weiteren ist es bequemer php.ini-Werte mittels vhost.conf oder .htaccess Dateien zu verändern.
Ich rate aber, besonders im Bezug auf Sicherheit, von PHP als Apache-Modul ab. Es sollte lieber auf CGI/FastCGI/SuPHP zurückgegriffen werden.

Die Frage bezieht sich auf mehrere User / vHosts

"Mehrere" sollte evtl. noch definiert werden.
Aber so lange man nicht den langsamsten vServer hat, ist CGI/FastCGI absolut kein Problem. Das läuft locker mit mehreren tausend vHosts. Beispielsweise lief/läuft eine ähnliche Konfiguration auf 1&1 Webhosting Servern mit ca. 10.000 vHosts pro Server.

 

[dev]

Wieviel RAM steckt denn in der Büchse?

Für 10k vHosts braucht man für FastCGI/fcgid in Verbindung mit PHP gigantische RAM-Mengen und eine sehr sorgfältige Konfiguration.

Wenn für jeden 3. vHost 1 Thread mit dem PHP-Interpreter vorgehalten wird, der nur 15 MB verbraucht, habe ich eine Speicherdauerlast von ca. 3.000 * 15 MB - das wären 45.000 MB! Wie soll das gehen? 48 GB RAM?

Ich habe aktuell ein System mit ca. 50 vHosts (jeder mit PHP), insgesamt verbrauchen die ein knappes GB (bei 20 MB PHP Speicherverbrauch). Dazu kommt das OS, die DBs etc..

Mit 16 GB RAM könnte ich 800 vHosts versorgen, bin aber immer noch nichtmal bei 1/10 der oben angegebenen Menge?!

 

[Bierteufel]

Ein klein wenig Offtopic:

Aber evtl. auch in Zukunft von Interesse

mod_ruid2

Mehr dazu liefert das "Orakel" Google...

 

[MTLServices]

Wieviel RAM steckt denn in der Büchse?

Es ist schon ca. 5 Jahre her, dass ich eine solche Hosting-Lösung in dem Umfang erarbeitet habe. Damals haben wir das mit mod_vhost_alias und CGI (nicht FastCGI) gemacht. RAM steckten ca. 2-4GB hinter (allerdings nur Apache und FTP, sonst keine Dienste). Und das lief alles 1a, sogar mit deutlich > 10.000 vHosts pro Maschine.

Aber der Vergleich mag hinken, da wir hier ja wohl eher über eine Plesk-Umgebung mit FastCGI reden.
Des Weiteren haben Parameter, wie memory_limit etc. ja auch noch ihre Auswirkungen auf die Last.

@Bierteufel: Danke!

 

[dev]

Mit CGI mag das gehen, da die CGI Prozesse im Gegensatz zu FastCGI nicht permanent im Speicher gehalten werden, sondern nach dem Request wieder sterben.

Das bezahlt man allerdings mit einem Neuladen des Interpreters für jeden (!!!) dynamischen Request. Teuer teuer...

Vor dem Hintergrund ist diese Aussage nicht korrekt, der Teufel steckt hier im konzeptionellen Detail:

Aber so lange man nicht den langsamsten vServer hat, ist CGI/FastCGI absolut kein Problem. Das läuft locker mit mehreren tausend vHosts.

Da die FastCGI permanent im Speicher gehalten werden, ist das mit mehreren tausend vHosts schon ein Problem.

 

[Joe User]

Auch PHP-CGI lässt sich permanent im Speicher halten, Stichwort suPHP und Co.
Zudem sind die Webhosting-Systeme der grösseren und grossen Anbieter nicht im Geringsten mit den marktüblichen RootServern vergleichbar. Dort kommen gerne grosse "Mainframes" beziehungsweise "Blades" mit Architekturen != x86 und etlichen GB RAM, sowie echte Unicies (Solaris, AIX, HP-UX oder z/OS, selten auch noch IRIX und Tru64) zum Einsatz.