Was für eine Konstelation Apache + PHP fahrt ihr (wenn überhaupt)

[theomega]

Das würde mich mal interessieren und vor allem mit wievielen Hits/Day.

[kase]

Apache 2.2 mit php-fcgi

Die Unterscheidung zwischen 2.0 und 2.2 ist eigentlich ziemlich sinnlos, denke ich zumindest. Ich habe trotz 2.2 mal auf 2.0 mit fcgi geklickt.

[theomega]

Hast du mod_fastcgi oder mod_fcgid im einsatz und mit ungefähr wievielen Hits auf PHP-Dateien pro Tag?

[Joe User]

RootForum: Lighty+PHP-FCGI mit ~18Mio Hits im letzten Halbjahr

[Roger Wilco]

Irgendwie fehlt mir da Apache httpd 2.0 + mod_suPHP. Oder fasst ihr das unter "Apache 2.0.x + PHP via CGI" auf?

[theomega]

Oki, könnte bitte ein Mod die Antworten anpassen (ich darf das irgendwie nicht): Einerseits bei den CGI-Lösungen dazuschreiben " (via suexec oder suphp) und die Apache 2.2 Lösung wegnehmen? Danke!

[kase]

Hast du mod_fastcgi oder mod_fcgid im einsatz und mit ungefähr wievielen Hits auf PHP-Dateien pro Tag?

mod_fcgid, mod_fastcgi würde ich inzwischen nicht mehr nehmen, besonders nicht mit apache 2.2. Zu Zeiten meines Apache2-php-fcgi Howtos war mod_fcgid noch ziemlich "jung" (das Howto entstand so ab Oktober 2004, die erste offizielle Version von mod_fcgid gab es glaube ich so März 2004), weswegen ich in diesem noch mod_fastcgi benutzt habe.

Hits sind nicht nennenswert, vielleicht 100 pro Tag :)

Ich hatte aber damals (Anfang 2005) einen Server von einem Online-Browser-Game mit Apache2.0 und mod_fastcgi nach meinem Howto konfiguriert, der _extrem_ viele Hits hatte, und sehr sehr stabil lief. (Im Schnitt waren eigentlich immer 1000+ User gleichzeitig online)

[Joe User]

Oki, könnte bitte ein Mod die Antworten anpassen (ich darf das irgendwie nicht): Einerseits bei den CGI-Lösungen dazuschreiben " (via suexec oder suphp) und die Apache 2.2 Lösung wegnehmen? Danke!

[x] Done

[theomega]

Dank dir.

Ich erstell die Umfrage nicht aus reinem Spaß. Ich habe im Moment eine Seite mit ca. 12 Mio Hits pro Monat nur auf PHP-Dateien (statische Inhalte mal aussen vor) die ich irgendwie am laufen halten muss. Bis jetzt lief das einigermaßen auf einem apache 1.3 und mod_php. Jetzt dachte ich einerseits wegen sicherheit und andererseits wegen der Geschwindigkeit steig ich auf mod_fastcgi und apache 2.0x um. Hat auf meinem Testserver auch problemlos funktioniert nur ehalten die Benutzer jetzt manchmal Internal Server Errors und es ist extrem schwer zu tracen. Deshalb überleg ich gerade wieder zu einer mod_php Version zurückzukehren, wobei mir schon klar ist, das ich sowohl die gewonnene Sicherheits alsauch die Performance dadurch aufgebe.

Falls mir jemand bei meinem Problem helfen will, der kann hier weiterlesen: http://www.rootforum.org/forum/viewtopic.php?t=44319

Ein Umstieg auf Lighttpd wäre zwar vermutlich die beste Lösung fällt leider im Moment flach weil ich einige hundert mod_rewrite Regeln umschreiben müsste um diese im lighttpd zum laufen zu bekommen.

Naja, ich bin mal gespannt auf weitere Infos

Gruß
TO

[aubergine]

Ich hab ja einiges an Dokus usw. in letzter Zeit gelesen und es war eigentlich immer davon die Rede das es nichts performanteres als mod_php gibt.

Sicherheitstechnisch natürlich eine Katasrophe wenn man sonst nichts tut ("nur" ein open_basedir angeben bringt bekanntlich schon eine Menge...), aber überlicherweise der Webserver Standard und das vorallem im shared hosting Betrieb.


Oder sieht es jemand so dass es eine performantere Konfiguration als mod_php gibt? (Von lighty Lösungen jetzt mal abgsehen)

[kase]

mod_php sollte normal performanter sein als jede php-fcgi Konfiguration. Die Stärken von php-fcgi liegen in der Sicherheit und den extrem guten Konfigurationsmöglichkeiten. Der Unterschied zwischen mod_php und php-fcgi ist aber recht gering, php-CGI Lösungen schneiden in Sachen Performance DEUTLICH schlechter ab.

[antondollmaier]

Bei nem Extremtest mit "ab" hat sich Apache2.0 mit mod_php als langsamer erwiesen, als lighty mit fcgi ... lighty hat trotz Load 113 noch problemlos gearbeitet (zwar verzögert, aber es lief), der Apache weigerte sich komplett ...


In Shared Hosting-Bereichen führt IMHO nichts an Apache (ob jetzt 2.0 oder 1.3) mit mod_suphp vorbei ... es ist bedeutend einfacher zu konfigurieren als PHP direkt als CGI, der Geschwindigkeitsverlust fällt nicht soo arg auf ... Der Sicherheitsaspekt ist aber ungeschlagen ...

[djcrackman]

Mittlerweile fahre ich das vierte Jahr mit Apache 1.3 und mod_php. Einige von euch wissen, dass ich ein free hosting Projekt betreibe - aktuell gehen da pro 14 Tage ~11,8 Mio Hits ein. Die Umstellung von 2 Apache-Instanzen auf insgesamt 16 (2x PHP4- und 2x PHP5-Proxy; pro PHP-Version 6 Hosts) hat ein Performance-Plus von unglaublichen 41% gebracht.

[kase]

Bei nem Extremtest mit "ab" hat sich Apache2.0 mit mod_php als langsamer erwiesen, als lighty mit fcgi ... lighty hat trotz Load 113 noch problemlos gearbeitet (zwar verzögert, aber es lief), der Apache weigerte sich komplett ...

Das liegt aber eher an dem lighty und nicht an php-fcgi. Kann mir nicht vorstellen, dass es bei einem reinen Apache-Vergleich auch so wäre. Falls doch, Daumen hoch, ich bin ja begeisterter php-fcgi Nutzer.

In Shared Hosting-Bereichen führt IMHO nichts an Apache (ob jetzt 2.0 oder 1.3) mit mod_suphp vorbei ... es ist bedeutend einfacher zu konfigurieren als PHP direkt als CGI, der Geschwindigkeitsverlust fällt nicht soo arg auf ... Der Sicherheitsaspekt ist aber ungeschlagen ...

Naja, der Geschwindigkeitsunterschied zwischen php als cgi (zB suphp) und php-fcgi ist schon recht groß, da wird dir einiges an Performance verloren gehn. Ich denke, dass man besser mit php-fcgi fährt, sicherheitstechnisch ist da quasi kein Unterschied.

[antondollmaier]

Naja, der Geschwindigkeitsunterschied zwischen php als cgi (zB suphp) und php-fcgi ist schon recht groß, da wird dir einiges an Performance verloren gehn. Ich denke, dass man besser mit php-fcgi fährt, sicherheitstechnisch ist da quasi kein Unterschied.

Ich hatte mir fastcgi vor längerer Zeit mal angeschaut und bin da an einer doch etwas aufwendigeren (schreibt man das jetzt nicht "aufwändigeren?") Konfiguration der vHosts "gescheitert" ... extra die Binaries kopieren, Skripte anlegen, ScriptAliases und sonstiges ...

suPHP wird geladen, in der zentralen Config eingestellt und gut is ... komfortabler gehts eigentlich fast nicht mehr ...


Mir gings halt darum, trotz Confixx den Server sichriger zu machen ... mit wenig Aufwand ...


Kann sein, dass sich die Konfiguration jetzt mit dem anderen Modul geändert hat, kann ich nicht sagen ... Falls ja - werde das dann mal auf nem Testsystem ausprobieren :)

Anton

[flo]

Bei dedizierten Kundenservern (eingeschränkter Benutzerkreis, definierte Projektserver) fahre ich eine einfache Apache2/mod_php-Lösung.

Für meine shared-Hosting-Lösungen bin ich vor einiger Zeit auf Apache2/mod_php und Pound gekommen - das ist definitiv absolut ressourcenfressend, aber jede Instanz läuft unter dem FTP-Benutzer/Gruppe und damit wäre dann auch sinnvolles WebDAV möglich.

Als Frontend hatte ich auf dem ersten Setup einen Apache2 am Laufen - die Performance war eine Katastrophe, ich war am Schrauben der Kernel-Buffer und es gab Probleme mit Authentifizierung und File-Uploads.

flo.

[dtdesign]

Bei mir erreichte folgende Lösung das derzeit annehmbarste Ergebnis:

System:
P4 2.8 GHz
1.024 MB Ram

Software:
Apache 2.0.x mit mod_security
-> 3 Instanzen
PHP 5.2.x als CGi mit suPHP
-> 6 Instanzen

Selbst bei mehr als 100k Hits pro Tag auf PHP-Skripte mit Datenbankzugriff auf MySQL lag die durchschnittliche Ladezeit bei 20ms. Trotz weiterer rechenintensiven Prozesse laufen die Seiten in der derzeitigen Konfiguration mit mehr als nur annehmbaren Geschwindigkeiten.

Lighttp hat bei mir nicht die gewünschten Erfolge gebracht, wahrscheinlich auch Grund von eigener Unfähigkeit ;)

Apache 1.3 ist bei mir gestorben, da dieser teilweise mit aktuellen Technologien einfach nicht mithalten kann, alleine das threaded worker Model ist meiner Meinung nach ungeschlagen. Mit viel Interesse schaue ich gen Apache 2.2 und dem perchild threaded Model...

mod_php scheidet bei mir aus sicherheitsbedenken aus, da aktuelle Techniken wie z.B.: suPHP und/oder suexec2 einfach mehr Möglichkeiten bieten einen VHost effektiv vom System abzuschotten bzw. ihm mit fastcgi/suexec2 sogar eigene PHP-Binaries zu unterbreiten.

Man sollte nicht die Tatsache aus den Augen verlieren, dass mein System zur Zeit ein Produktivsystem darstellt und irgendwelchen tollen, bunten Spielereien per se keine Nächstenliebe erfahren. Zudem schließe ich von diesem System konsequent unstable/testing aus, diese werden höchsten in einer Virtual Machine zwecks rumspielen installiert. So bleibt man auf der Höhe der Zeit, hat allerdings ein System mit 99,99% Verfügbarkeit.

Ich denke, dass dies die zentrale Überlegung ist, auf welche Konfiguration und/oder Kombination man setzt.

Gruß
dtdesign

[flo]

Zudem schließe ich von diesem System konsequent unstable/testing aus, diese werden höchsten in einer Virtual Machine zwecks rumspielen installiert.

No Offence, aber die paar Tage werden an der Stabilität nicht mehr viel ändern :-)

[daemotron]

Ich denke mal, er bezieht das allgemein auf den Status eines Software-Pakets und nicht auf Debian - würde mich jedenfalls wundern, wenn das Bestandteil von Sarge wäre:

Apache 2.0.x mit mod_security
-> 3 Instanzen
PHP 5.2.x als CGi mit suPHP
-> 6 Instanzen

Just my 0.02€ 8)

[dtdesign]

Korrekt erkannt jfreund, der Apache 2.0 ist tatsächlich Bestandteil von Debian, wobei bei mod_security eine ältere Version von Hand kompiliert wurde.

PHP5 mit suPHP beziehe ich über http://www.dotdeb.org , da ich einfach nicht auf PHP5 verzichten kann und ich mein System nicht mit Debians "EXPERIMENTAL" PHP5 Lösungen schreddern will ;)

Gruß
dtdesign

[flo]

Ich nutze die Debian-Pakete (MySQL, Apache, PHP) überhaupt nicht, gerade wegen der relativ häufigen Paketgefrickel, wenn man doch mal wegen aktueller Pakete unstable benutzt, das habe ich vor ein paar Jahren mal mitgemacht, momentan läuft nur einer meiner vServer mit Standardpaketen - MySQL war nach einem Tag noch nicht durch, da hab ich den Rest auch bleiben lassen.

Aber selbst die Config des Debian-Apachen ist mir zu unflexibel und durch die einzelnen Backends ist es durch ein einfaches apachectl restart bei mir nicht getan.

flo.

[arty]

Hi,

wir verwenden bei Kunden immer die Kombination Apache 2.0 / mod_php(4|5).

-arty

[ghoster1970]

Ich bin durch einige Beiträge betreffs Lighttpd neugierig geworden. Einmal getestet, eine Woche genossen und danach den Apachen auf 3/5 Servern ersetzt.

spawn-fcgi ist wirklich genial IMHO.

[braindead]

Lighty + PHP-FCGI + APC im Moment so ca. 1,5 Mio Hits am Tag auf PHP Datein (die sind aber sehr stark gecachet). Das ganze auf einem Opteron 146 mit 1GB RAM und Debian Sarge als OS.

[rootsvr]

Die Suexec/Fastcgi Anleitung nach Kase seit 2005. Umstellung auf fcgid steht irgendwann an, eilt aber nicht.

Seit gestern Etch, also Apache 2.2 etc..

Hits: wenige! (vielleicht 200000 im Monat)