Welche Funktionen stehen bei PHP als CGI nicht mehr zu Verfügung?

[kase]

Nein, da mir kein php-Accelerator/Cacher bekannt ist, der mit php als CGI funktioniert. Wobei funktioniert ist etwas falsch formuliert, es gibt schon welche, die funktionieren, aber wenn immer nur 1 Request gecached wird, weil sich danach das php-Binary wieder beendet, dann ist das ganze sogar langsamer als ohne Accelerator.

[hotzi]

Hm die Entscheidung zwischen performancen und sicherheit / php als user wird da echt schwer.

Faktisch müsste ich einem user ann kündigen, falls es mein neuer Server mit suphp dann nicht packt. Aktuell sind die Resourcen unter mod_php auf nem AMD Opteron 146 / 1 Gbyte schon zu eng. Der neue ist DUAL Core Opteron 1218 mit 4 Gbyte RAM, nicht dass suphp die Hardware-Performance-Vorteile zunichte macht...

[hotzi]

Nein, da mir kein php-Accelerator/Cacher bekannt ist, der mit php als CGI funktioniert. Wobei funktioniert ist etwas falsch formuliert, es gibt schon welche, die funktionieren, aber wenn immer nur 1 Request gecached wird, weil sich danach das php-Binary wieder beendet, dann ist das ganze sogar langsamer als ohne Accelerator.

Zend Optimizer (ok nicht mit nem Cache wie Eaccel vergleichbar) sollte aber mit cgi rennen... wenn man schon was "tunen" will..

[dtdesign]

Dann wähle doch einfach Apache2 + mod_fastcgi/mod_fgi + PHP5 (oder PHP4) als CGI-Binary.

Debian selber bringt CGI-Binaries für PHP5 ab Etch von Werk aus mit inkl. FastCGI. Zusätzlich kannst du auf suexec2 setzen um PHP abzusichern.

suPHP wertet seine Configs erst zur Laufzeit aus, bei suexec hat man erstmal ein wenig Arbeit vor sich, aber es bringt den gewünschten Effekt bei fast der selben Performance wie mod_php.

Gruß
dtdesign

[jabba]

su_php bzw php als cgi ist DEUTLICH langsamer als mod_php, ich denke mindestens um den Faktor 2-3.

Immer wider derselbe Unsinn!
suPHP führt Scripte genauso schnell aus wie mod_PHP. Warum sollte es auch langsamer tun, denn schließlich wird dasselbe PHP benutzt. Es wird nur anders aufgerufen.
Der Aufruf verbraucht allerdings nur Milisekunden und spielt bei Webanwendungen keine spürbare Rolle, solange die Server nicht im Überlastbetrieb laufen. suPHP verbraucht also mehr Rescourcen (Speicher!) und deswegen kann man nicht so viele Kunden auf eine Maschine quetschen.
Shared Webhosting mit mod_PHP ist aus sicherheitskritischer Sicht UNBEDINGT abzuraten und das ist IMMER wichtiger als ein paar Millisekunden Performanceunterschied.

[hotzi]

Es ist in der Praxis langsamer, immerhin müssen bei gut besuchten Servern viele procs aufgerufen werden.

Faktor2 ist nach meinen Tests sicher nicht unrealistisch.

Besonders schlimm ists, wenn Leute irgendwelche Chats installieren, die ziemlich oft ein kleines Script aufrufen.

Aber klar, ich hab den Umstieg auf suphp nicht bereut und werde mod_php fürs Hosting nicht wieder einsetzen.

[rootsvr]

suPHP führt Scripte genauso schnell aus wie mod_PHP. Warum sollte es auch langsamer tun, denn schließlich wird dasselbe PHP benutzt. Es wird nur anders aufgerufen.

Bist Du da sicher?
suphp geht den weg wie cgi: Es startet eine php Instanz für einen Aufruf und beendet sie dann wieder.
Meine php-binarys sind ~2 MB groß, die müßen also geladen und in den Speicher geschrieben werden, das dauert.

was kein Unterschied macht ist mod-cgi und mod-suphp (suphp macht nichts anderes als als cgi außer vor dem Aufruf den User zu ändern). Mod-php wird immer deutlich schneller sein, auch fastcgi wird schneller sein (da wird einmal geladen und dann mit diesem Prozess X Abfragen abgehandelt)

mit dem etwas anderen Aufruf ändert sich eine Menge! generell ist suPHP in großen Hostingsachen sicherlich sinnvoll, bei Performancerelevanz und Sicherheitswünschen ist fastcgi/suexec sicherlich besser.

mod_php nutzt man wenn man nur eine Applikation/einen Kunden hat.

[jabba]

Nein, wir haben diese Erfahrungen nicht gemacht. Auf Servern, die nicht im Überlast laufen ist kein spürbarer Geschwindigkeitsunterschied zu merken. Wir haben umfangreiche Tests mit CMS wie typo3 und joomla gemacht. Alles wird exakt gleichschnell dargestellt.
Wir haben auch einen Test in einer (sehr) großen Community gefahren, wo zwei Beispielsinstallationen auf derselben Maschine einmal mit suPHP und einmal mit mod_PHP installiert war. Ergebnis: Kein Unterschied!! (von den Millisekunden Unterschied wegen Programmstarts mal abgesehen. Das spürt man nicht beim Surfen)

Richtig ist, weil viel mehr Rescourcen gezogen werden, so das ein Server eben weniger "verträgt". Chats sind daher noch tödlicher, als sie sowieso schon sind. Ein Server kommt also schneller in den "roten Bereich". Wichtig ist daher ausreichend RAM einzubauen. Auch Dumping-Hoster ohne sinnvolle Kalkulation, wo hunderte oder gar tausende Webs auf einer Maschine liegen werden hiermit nicht glücklich werden - aber da ist mir ziemlich egal :-)

[hotzi]

Tja, wie gut dass jeder so seine eigenen Tests machen kann.

[jabba]

Meine php-binarys sind ~2 MB groß, die müßen also geladen und in den Speicher geschrieben werden, das dauert.

Wie lange dauert das denn tatsächlich?
Auf einer Maschine wo dieser Vorgang sekündlich durchgeführt wird, liegt das Binary bereits im Speicher (Cache) und wird doch gar nicht echt von der Platte geholt. Hin und wieder gibt es mal einen Erstaufruf - na und? Selbst so ein Binary von Platte zu laden spürt man doch nicht mehr bei der heutigen Hardware. Hier geht es nur um Millisekunden und die spielen beim Surfen keine Rolle.

Problematisch und das habe ich ja beschrieben ist der viel höhere Rescourcenverbrauch (RAM). Das hat aber nichts mit Geschwindigkeit oder Performance zu tun.

Nachtrag:
FastCGI ist noch besser (Vorteil vom mod_PHP und CGI werden vereint) aber hat noch mehr Rescourcenprobleme, weil einfach viel mehr Speicher benötigt wird. RAM ist hier das allerwichtigste.

[hotzi]

Das ist mir ehrich gesagt Wurst, weil ich kann nur beurteilen, was ich selber gesehen habe.

Übrigens: 0.25 LOAD, 1.4 Gbyte RAM von 4 belegt, bla blupp

[dtdesign]

Wie lange dauert das denn tatsächlich?

Definitiv länger als mod_php oder via F(ast)CGI.

Auf einer Maschine wo dieser Vorgang sekündlich durchgeführt wird, liegt das Binary bereits im Speicher (Cache) und wird doch gar nicht echt von der Platte geholt.

Wenn man mit einem Apache-Servermodul (aka. mod_php) arbeitet trotzdem langsamer.

Hin und wieder gibt es mal einen Erstaufruf - na und?

Es macht einen Unterschied und gerade in der heutigen Zeit merkt man, ob ein Server die Seite eine halbe Sekunde später ausliefert.

Selbst so ein Binary von Platte zu laden spürt man doch nicht mehr bei der heutigen Hardware.

Nicht jeder hat einen Dual-Core mit 4 GB Ram. Nur weil man Resourcen hat, heißt das noch lange nicht, dass ich alle gnadenlos und vorallem sinnlos verbraten muss.

Hier geht es nur um Millisekunden und die spielen beim Surfen keine Rolle.

Sind leider nicht immer Milisekunden, Server mit weniger Kapazitäten und anderen Diensten werden durchaus länger brauchen.

Problematisch und das habe ich ja beschrieben ist der viel höhere Rescourcenverbrauch (RAM). Das hat aber nichts mit Geschwindigkeit oder Performance zu tun.

Wenn du weitere Dienste hast schon und das unter Umständen immens. Ich habe selber den Fall erlebt, dass ein DoS-Angriff den Server ins stotternt brachte, weil er OOM war (dank suPHP).

Nachtrag:
FastCGI ist noch besser (Vorteil vom mod_PHP und CGI werden vereint) aber hat noch mehr Rescourcenprobleme, weil einfach viel mehr Speicher benötigt wird. RAM ist hier das allerwichtigste.

Blödsinn. Ich habe derzeit 11 PHP-Instanzen im Speicher hängen und die hocken größtenteils fleissig im Shared Memory. Ergo ist der Mehrverbrauch gering.

Zudem ist dieser Ram-Verbrauch kalkulierbarer als auf "normaler" CGI-Basis, ergo hat man mehr Kontrolle über seine Resourcen.

Gruß
dtdesign

[jabba]

Das ist mir ehrich gesagt Wurst, weil ich kann nur beurteilen, was ich selber gesehen habe.

Ich will Dich doch gar nicht überzeugen. Ist mir auch ziemlich egal was Du machst. Kann nur meine eigenen Erfahrungen berichten.

Nicht jeder hat einen Dual-Core mit 4 GB Ram. Nur weil man Resourcen hat, heißt das noch lange nicht, dass ich alle gnadenlos und vorallem sinnlos verbraten muss.

Jeder muss selbst wissen, was einem wichtig ist. Mir liegt die Sicherheit sehr am Herzen und daher betrachte ich es nicht als sinnlos an, ein PHP so einzusetzen das mehr Rescourcen braucht, aber dann deutlich sicherer ist. Wenn Du einen Server für Dich alleine nutzt kannst Du auch problemlos mod-PHP erinsetzen. Wurde oben ja auch schon mal so gesagt.

[dtdesign]

Jeder muss selbst wissen, was einem wichtig ist. Mir liegt die Sicherheit sehr am Herzen und daher betrachte ich es nicht als sinnlos an, ein PHP so einzusetzen das mehr Rescourcen braucht, aber dann deutlich sicherer ist. Wenn Du einen Server für Dich alleine nutzt kannst Du auch problemlos mod-PHP erinsetzen. Wurde oben ja auch schon mal so gesagt.

Kommando zurück, das meinte ich gar nicht. Ich setze selber Lighty in einer chroot-Umgebung ein, zusammen mit Spawn-CGI um die Besitzer zu setzen (via FastCGI in Lighty eingebunden).

Faktisch besitzt suPHP einfach zu viel Overhead, der bei FastCGI nicht in dem Maße auftritt. mod_php ist am einfachsten zu installieren und mit einer gescheiten chroot, suhosin, anständiger ini etc. kann so ein System die selben Sicherheitsmerkmale aufweisen.

Pauschal alles zu verdonnern ist falsch, wenn man weiss wie, schafft man auch das Scheunentor dicht zu machen.

Gruß
dtdesign

[rootsvr]

Faktisch besitzt suPHP einfach zu viel Overhead, der bei FastCGI nicht in dem Maße auftritt. mod_php ist am einfachsten zu installieren und mit einer gescheiten chroot, suhosin, anständiger ini etc. kann so ein System die selben Sicherheitsmerkmale aufweisen.

Aber selbst bei einer gescheiten php.ini bei mod_php hat man nur einen User.. betreibt man Service für unterschiedliche User ist das eigentlich ein klares NoNo, kann doch ein User die Daten des anderen nutzen/lesen. da hilft auch prinzipbedingt nicht das ändern der einen php.ini.

Meiner Meinung nach hat alles (bis auf mod_cgi) seinen Berechtigung.
- suPHP wenn es sicher sein soll und man VIELE User hat
- fastcgi, wenn man weniger User hat und Performance/Sicherheit gebraucht werden.
mod_php wenn es nur einen User gibt aber Perormance wichtig ist.

[hotzi]

So ähnliche Gedanken hatte ich auch.

wenn ich einen user / web habe, dann kann ich Missbrauch im Filesystem einen Riegel vorschreiben und muss mich net auf tausend Patches /Addons für PHP verlassen.

[kase]

Immer wider derselbe Unsinn!
suPHP führt Scripte genauso schnell aus wie mod_PHP.

Performance

Setzt man PHP als CGI-Programm ein, ist die Performance sehr schlecht. Für jeden HTTP-Request startet der Webserver eine neue Instanz des PHP-Interpreters, welche jedes Mal den Quelltext des aufgerufenen Skriptes neu übersetzt. Um den Start der Interpreter-Instanzen zu sparen, setzt man PHP üblicherweise als Servermodul, d.h. Teil der Webserver-Prozesse, oder über FastCGI ein. Da bei kleinen Skripten das Starten des PHP-Interpreters bei weitem am meisten Zeit verbraucht, führt diese Maßnahme zu einer drastischen Leistungssteigerung.

Ich selbst habe schon mehrere stark besuchte Webserver von suphp auf fastcgi umgestellt, und der Unterscheid ist überwältigend. Server, die mit suphp vor allem bei der CPU komplett am Limit liefen, hatten mit fastcgi sogar noch Leistungsreserven.

Natürlich dauert es nicht wirklich lange, den PHP-Prozess zu starten, aber trotzalledem kostet es CPU. Gerade in der heutigen Zeit, in der sehr viel auf AJAX/JSON basiert, und diese Zugriffe nur "winzige" PHP Scripte aufrufen, ist der Overhead, das PHP-Binary zu starten, entsprechend groß.