RootForum Community

kase wrote: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.

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

eAccelerator Homepage wrote: Anforderungen
Apache 1.3, Apache 2.0 (prefork), mod_php4/5, autoconf, automake, libtool, m4

kase wrote: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...

kase wrote: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.

SunTzu wrote:

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

...aber...:

eAccelerator Homepage wrote: Anforderungen
Apache 1.3, Apache 2.0 (prefork), mod_php4/5, autoconf, automake, libtool, m4

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

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.

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.

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

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.

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

CaptainCrunch wrote: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.

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

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

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