Debian Sarge, Apache2, Suexec2, mod_fastcgi, php5-fcgi HowTo

[carl]

Außerdem will ich hier im Post nochmals deutlich schreiben, dass wer Probleme mit PHP_FCGI_CHILDREN hat, und keinen guten bzw pasenden Wert findet, die Option PHP_FCGI_CHILDREN einfach komplett aus seinem php-fcgi-starter-Script rauslässt. PHP regelt dann das Prozess-Management komplett von alleine.

Danke für den Tipp an kenzo.

Ich habe folgendes gefunden:

Note: When using PHP 4.3.0 and above, the default setting for PHP_FCGI_CHILDREN is "0". If you fail to set this variable to a higher value than the default, the PHP binary will not fork resulting in only one PHP request being processed at a time.

interessant ist auch noch die funktion:

PHP_FCGI_MAX_REQUESTS - the number of requests each PHP child process handles before exiting. If not set, defaults to 500.

[kase]

Lag es daran oder ist das nur ein Comment von dir?

Soviel ich weiß, ist aber genau das das Ziel, denn so spawnt php selbst keine Prozesse, und wenn fastcgi zB 5 neue anfordert, entstehen auch nur 5 neue FCGI-Prozesse. Wenn man die Variable höher setzt, spawnt php von alleine Children, was zur Folge hat, dass, wenn fastcgi zB 5 neue Prozesse requestet, php gleich 5* PHP_FCGI_CHILDREN neue Prozesse spawnt, was natürlich meistens viel zu viele sind.

Aber da könnte auch kenzo nochmal drauf eingehen, von dem ich das übernommen habe, denn ich selbst setze IMMER die PHP_FCGI_CHILDREN Variable...

[carl]

Das ist nur ein Comment von mir.
Bin per Zufall darauf gestossen.

[kase]

Welchen Wert benutzt du oder lässt du die Variable ebenfalls unedfiniert?

[carl]

ich benutze nun:

PHP_FCGI_CHILDREN=8
PHP_FCGI_MAX_REQUESTS=500

funktioniert bis jetzt perfekt.

Habe jetzt auch den eAccelerator (nachfolger von mmcache) installiert. funktioniert bis jetzt wunderbar mit fastcgi.
jedoch sollte man ihn nur mit php4 benutzen. für die benütztung mit php5 ist er noch nicht zu empfehlen, da noch einige fehler bestehen.
doch die entwickler sind fleissig am entwickeln.

http://eaccelerator.net/HomeDe?lg=de

Installationsanleitung ist auf der Homepage zu finden.

[suntzu]

Habe jetzt auch den eAccelerator (nachfolger von mmcache) installiert. funktioniert bis jetzt wunderbar mit fastcgi.

...aber...:

Anforderungen
Apache 1.3, Apache 2.0 (prefork), mod_php4/5, autoconf, automake, libtool, m4

Tut's das wirklich so zusammen, wie es soll?

[carl]

ja funktioniert bei mir ohne probleme.

[suntzu]

Und das Ding cached die Seiten auch richtig? Denn wenn ich mich recht entsinne stand auf den alten Projektseiten, dass der accelerator nicht mit php-cgi zusammenarbeitet... Klar, installieren kann ich das auch, das System wird danach auch noch laufen, aber macht das Ding dann auch was es soll?

[kenzo]

Soviel ich weiß, ist aber genau das das Ziel, denn so spawnt php selbst keine Prozesse, und wenn fastcgi zB 5 neue anfordert, entstehen auch nur 5 neue FCGI-Prozesse. Wenn man die Variable höher setzt, spawnt php von alleine Children, was zur Folge hat, dass, wenn fastcgi zB 5 neue Prozesse requestet, php gleich 5* PHP_FCGI_CHILDREN neue Prozesse spawnt, was natürlich meistens viel zu viele sind.

Aber da könnte auch kenzo nochmal drauf eingehen, von dem ich das übernommen habe, denn ich selbst setze IMMER die PHP_FCGI_CHILDREN Variable...

Ich musste ja bei mir sogar noch restriktiver vorgehen und habe "-startDelay 15" gesetzt, weil *immer* nachgespawnt wurde und dann in rauen Mengen. Ich bin mir noch nicht sicher, wo dahingehend das Problem bei mir liegt - nachdem allerdings keine PHP-Prozesse mehr nachgespawnt wurden, war die Performance gigantisch - ganz im Gegenteil, sobald nur einige wenige mehr da waren, brach die Performance sogar ein. Werde das mal weiter beobachten und ggf. versuchen, das (wenn mal wieder Zeit vorhanden ist, was noch etwas dauern kann) auf einem geeigneten Testsystem nachzuvollziehen bzw. weiter einzugrenzen.
Edit:

Wieso das ganze nun mit php 5.0.3 funktioniert und mit php 4.3.10 nicht, kann ich dir aber auch nicht sagen, theoretisch müsste es ohne Probleme mit beidem funktionieren.

Läuft hier mit 4.3.10.

[andreask2]

Hallo!

Habe jetzt auch den eAccelerator (nachfolger von mmcache) installiert. funktioniert bis jetzt wunderbar mit fastcgi.

...aber...:

Anforderungen
Apache 1.3, Apache 2.0 (prefork), mod_php4/5, autoconf, automake, libtool, m4

Tut's das wirklich so zusammen, wie es soll?

Folgendes könnte in dem Zusammenhang interessant sein:

Code: Select all

However, as more people upgrade from the now ancient Apache 1.x to Apache 2.x, those using the multi-threaded mode for Apache 2 discover mod_php uses an enormous amount of memory, due to duplication of data between threads and processes. For example, currently available PHP optimizers share "compiled" PHP code between threads, but not between threads from separate Apache 2 processes. Even FastCGI processes (mmcache, eaccelerator, etc.) can cause duplication of the "compiled" cache in memory, unless all such processes share the same parent, do to the shared memory mechanisms they use. We're not aware of any FastCGI compatible PHP optimizer implementation that avoids such duplication. Note that GB sPHPs avoids this issue by keeping a single, shared parent process that owns the shared memory segments.

(Quelle: http://www.goldenbluellc.com/PHP_Security#Why_is_the_PHP_DSO_for_Apache_.28mod_php.29_so_popular.3F)

Und diese Diskussion im eAccelerator-Forum bei sf.net:
http://sourceforge.net/forum/forum.php? ... _id=416741

Ich verwende lighttpd mit php5 über mod_fastcgi, wo die PHP-Prozesse durch das in lighttpd enthaltene spawn-fcgi binary gestartet werden können. Und bisher klappt das eigentlich sehr gut, auch mit eAccelerator, http://lighttpd.net läuft unter anderem mit derselben Konfiguration. Mit eAccelerator habe ich lediglich ein php5-spezifisches Problem, welches im CVS aber bereits gefixt ist.

Grüße
Andreas

[kase]

Das Howto ist "umgezogen", nun zu finden bei Debianhowto.de, da es dort wesentlich übersichtlicher und für mich auch leichter zu administrieren ist.

Natürlich könnt ihr weiterihn hier eure Diskussionen führen, und Comments und Anregungen posten.

http://www.debianhowto.de/howtos/de/apa ... sarge.html

[koc]

hi

bei mir kommt dieser fehler bei der php installation nachdem configure befehl:

make: *** No targets specified and no makefile found. Stop.

also nachdem ich make eingebe

[kase]

Dann gibst du entweder im falschen Verzeichnis "make" ein, oder bei dem "./configure ..." ist schon irgendwas schief gegangen, und du hast trotzdem "make" eingegeben.

Poste mal die Ausgabe von "ls -l" von dem Verzeichnis, wo du dein "make" eingibst.

[aule]

Da es zur Zeit weder offizielle PHP5 noch PHP4-fcgi Pakete von Debian gibt, müssen wir PHP selbst compilieren. Dies ist allerdings nicht sonderlich schwer, da wir nur PHP-Binarys benötigen, und diese nicht einmal ins System installieren, sondern komplett unabhängig in ein eigenes Verzeichnis.

Zunächst verlassen wir root und su(en) zu einem User mit eingeschränkten Rechten.

Welchen User soll ich da nun nehmen?
Soll ich einen eigenen User ala php5_user machen oder was?
Ist es nicht viel einfacher, das Ding auf der read_only gemounteten /usr/local oder ähnlichem zu installieren?

Aule

[kase]

Du kannst deinen ganz normalen "Standard" User verwenden, mit dem du dich per SSH einloggst (was ja hoffentlich nicht root sein wird) oder du kannst auch einfach einen neuen User dafür anlegen, dort sind deiner Phantasie keine Grenzen gesetzt ;)

[andreask2]

Mich würde dazu interessieren, ob der PHP-Beschleuniger Turck MMCache damit weiterhin funktioniert. Hat das jemand schon mal zusammen probiert?

Naja, an Turck MMCache wird seit weit über einem Jahr nicht mehr weiterentwickelt, ich würde jedem Anwender dringend den Umstieg auf eAccelerator ( http://eaccelerator.net/ ) empfehlen, denn:

Code: Select all

eAccelerator is a further development from mmcache PHP Accelerator & Encoder. It increases performance of PHP scripts by caching them in compiled state, so that the overhead of compiling is almost completely eliminated.

Wie es aussieht haben sich die Entwickler, die Turck MMCache weiterentwickeln wollen dort versammelt, und haben auch schon einige Probleme behoben.

Und zum eigentlichen Problem, siehe Links aus http://www.rootforum.org/forum/viewtopi ... 812#212812

[captaincrunch]

Ach ja, mal ganz nebenbei: gibt's irgend einen Grund, warum du das PHP-Binary nach der Kompilierung nicht strippst?

[kase]

Ach ja, mal ganz nebenbei: gibt's irgend einen Grund, warum du das PHP-Binary nach der Kompilierung nicht strippst?

Nein, hat keinen speziellen Grund...
Wie stark macht sich das denn bemerkbar? Und vor allem, welcher Strip-Level ist zu empfehlen? (--strip-debug, --strip-unneeded, --strip-all, ...)

[captaincrunch]

Durch den Einsatz von --strip-unneeded ist mein PHP-Binary (5.0.3, was aber nichts mit dem Howto hier zu tun hat) noch mal zusätzlich um ca. 300KB geschrumpft. Bei den 10 PHP-Prozessen, die ich meinen lighthttpd spawnen lasse, sind das immerhin schon mal wieder ~3 MB mehr Speicher für andere Geschichten. Probleme dadurch: keine.
Ich selbst verwende bei so etwas eigentlich ausschließlich "nur" --strip-unneeded, das aber eher aufgrund einer Recht speziellen Compiler- / glibc-Kombination bzw. der dabei zum Einsatz kommenden Patches. Im Normalfall tut ein "--strip-all" nicht wirklich weh.

[kase]

Durch den Einsatz von --strip-unneeded ist mein PHP-Binary (5.0.3, was aber nichts mit dem Howto hier zu tun hat) noch mal zusätzlich um ca. 300KB geschrumpft. Bei den 10 PHP-Prozessen, die ich meinen lighthttpd spawnen lasse, sind das immerhin schon mal wieder ~3 MB mehr Speicher für andere Geschichten.

Normalerweise sollte das aber Shared sein, womit du dann nicht 10*300 kb sondern nur 1*300 kb sparst. Kannst mich aber gerne berichtigen, sollte das nicht stimmen :)

[aule]

Noch so eine "Gibt es irgendeinen Grund"-Frage:

Gibt es irgendeinen Grund, dass du das Starter-Script in /var/www/php-fcgi-scripts/VHOST und nicht in /var/www/VHOST/php-fcgi-scripts
ablegst? Das hätte den Vorteil, dass man eine einfachere (Verzeichnis-)Schablone für einen VHost anlegen könnte

Aule

[kase]

Einen direkten Grund gibt es nicht. Da der php-fcgi-starter aber eine sehr wichtige "Anwendung" ist, hat die eigentlich im vhost-Verzeichnis nichts zu suchen, vor allem, weil darauf unter Umständen ja sogar der User ftp oder scp Zugriff hat. Das wäre fast so, als würde man das php-Binary in den vHost legen, was man natürlich ebenfalls nicht machen "sollte".

[aule]

Bei mir haben die Clients nur Zugriff auf www, also werde ich das trotzdem mal probieren.

Ahja, hab ich fast vergessen: ;)
Danke für dieses großartige Howto. Ich lasse das mal auf einen schwach besuchten Server los (ist schon passiert). Wenn was nicht funktioniert, schreie ich


Aule


EDIT: Nachdem es einige Probleme bezüglich vexim(PEAR) und php-fcgi gegeben hat, funktioniert jetzt alles. Gutes Howto!

[kase]

EDIT: Nachdem es einige Probleme bezüglich vexim(PEAR) und php-fcgi gegeben hat, funktioniert jetzt alles. Gutes Howto!

Habe dein Edit gerade entdeckt, hoffe du schaust nochmal rein... Könntest du die Probleme erläutern, dass ich sie gleich ins Howto einarbeiten kann?

[Anonymous]

Ich habe das HowTo auch auf einem frisch installierten Debian Sarge 3.1 Testing Server ausprobiert. Ich habe da aber so meine Probleme:
Ich habe in /var/www/meyma/web/ eine Datei phpinfo.php angelegt. Diese Datei führt nur die Funktion phpinfo(); aus. Wenn ich mit dem Browser auf diese Datei gehe, gibt Apache diese Meldung aus:

The requested URL /cgi-bin/php-fcgi-starter/meyma/web/phpinfo.php was not found on this server.

In der error.log vom Apachen steht zu diesem Ereignis:

(2)No such file or directory: FastCGI: stat() of "/usr/lib/cgi-bin/php-fcgi-starter" failed

Die anderen Logs ergeben keine Fehler. Ich bin 100%ig nach dem HowTo vorgegangen. Vielleicht könnt ihr mir ja helfen.

Meyma