PHP mit fast-cgi: Welche Funktion hat mod_fastcgi.so?

[testit]

Hallo!

Um PHP5 parallel zu PHP4 betreiben zu können, habe ich PHP5 mit fastcgi realisiert.

Das Ganze funktioniert allerdings auch OHNE einem in der httpd.conf aktivierten mod_fastcgi. Die PHP5-Scripte laufen einwandfrei parallel zu PHP4-Scripten.

Ich frage mich nun, in welchen Fällen man mod_fastcgi (oder mod_fcgi) eigentlich einsetzt/benötigt, da - wie oben geschildert - das Ganze auch OHNE mod_fastcgi mit einem Wrapper-Script läuft.

Kommen die eigentlichen Vorzüge von fastcgi möglicherweise erst mittels Einsatz von mod_fastcgi zum Tragen (bspw. dass ein gestarteter PHP-Prozess sozusagen als "Dämon" eine gewisse Anzahl von Requests existiert, bevor neu "geforked" wird?


Freundliche Grüsse
testit


httpd.conf

]#LoadModule fastcgi_module     libexec/apache/mod_fastcgi.so
#AddModule mod_fastcgi.c

[...]

<Directory "/usr/local/www/htdocs/domain">
    Options -Indexes FollowSymLinks +ExecCGI
    AllowOverride AuthConfig FileInfo
    AddHandler php5-fastcgi .php .php5
    Action php5-fastcgi /cgi-bin/php.cgi
    Order allow,deny
    Allow from all
</Directory>
 
<Directory "/usr/local/www/htdocs/domain/cgi-bin">
  Options -Indexes FollowSymLinks +ExecCGI
  AllowOverride AuthConfig FileInfo
  Order allow,deny
  Allow from all
</Directory>

php.cgi

### Set PATH ###
PHP_CGI=/usr/local/bin/php-cgi
PHP_FCGI_CHILDREN=4
PHP_FCGI_MAX_REQUESTS=1000
### no editing below ###
export PHP_FCGI_CHILDREN
export PHP_FCGI_MAX_REQUESTS
exec $PHP_CGI .php5

 

[Bytesplit]

Deine Beschreibung sieht mir ganz nach einem normalen CGI-Start aus. D.h. für jedes PHP-Skript wird zur Ausführung ein PHP-Interpreter angefeuert. Kann u.U. einiges an IO-Last bedeuten.

Du solltest das daran erkennen können das FCGI-Children u. Max Requests nicht zum tragen kommen. Bei mir laufen nach dem Start vom httpd auch 8 PHP-Interpreter und warten auf Anfragen. Das spart einfach viel Zeit wenn viele Seiten angefordert werden.

Caching dürfte beim einfachen 1x-Start auch ein Problem sein, da jede Ausführung aufs neue für sich die Umgebung initialisiert.

Bau doch mal mit apachebench ein kleines Last-Szenario und lass ein paar parallele Requests laufen. So 1000 z.B....

Da sollte sich doch ein Vorteil gegenüber des einfachen CGI-Modus zeigen.

 

[testit]

Hallo Bytesplit,

ich teile Deine Meinung!

Nach allem, was ich herausfinden konnte, scheint das fastcgi_mod so eine Art "Prozessmanager" für die FastCGI-Aufrufe zu sein.

Ich habe nun auch mal versucht, das Ganze unter Anwendung von mod_fastcgi zum Laufen zu bekommen, scheitere aber nochn an diversen Fehlermeldungen, wie bspw.:

" execle() failed: Exec format error
[Sun Jun 20 20:26:57 2010] [warn] FastCGI: (dynamic) server "/usr/local/www/htdocs/domain/test.php" (pid 89637) terminated by calling exit with status '255'"

Könntest Du mir vielleicht einmal Deinen Auszug aus der Apache-httpd.conf zeigen?
Bei Dir scheint es ja zu laufen!


Freundliche Grüsse
testit

 

[Bytesplit]

Hm, hast Du schonmal geprüft ob Dein php-cgi Programm auch mit fcgi-Support gebaut wurde? Aus folgenden Howto habe ich diese Zeilen extrahiert:

Mach ein:

# /usr/local/bin/php-cgi -v

Im Ergebnis solltest Du dann unter anderem auch bekommen:

(cgi-fcgi)

Das garnicht schlechte Howto habe ich hier gefunden: http://www.cyberciti.biz/faq/freebsd-apache22-fastcgi-php-configuration/

Das spart mir jetzt natürlich erstmal jede Menge Tipparbeit.

Achso... mod_fcgi ist was anderes als mod_fastcgi. Ich habe mit fcgid die besseren Erfahrungen gemacht, es braucht weniger Speicher und lief bei mir stabiler.

Falls Du damit noch immer nicht weiterkommst, muss ich mal auf meinen Server SSH'en und meine eigene Konfig anschauen.

 

[reakktor]

Kommen die eigentlichen Vorzüge von fastcgi möglicherweise erst mittels Einsatz von mod_fastcgi zum Tragen (bspw. dass ein gestarteter PHP-Prozess sozusagen als "Dämon" eine gewisse Anzahl von Requests existiert, bevor neu "geforked" wird?

Fast-CGI ist als CGI-Schnittstelle zu einem (eigentlich) bereits laufenden Dienst/Prozess gedacht, über den normalerweise per Socket kommuniziert wird.

Ich frage mich nun, in welchen Fällen man mod_fastcgi (oder mod_fcgi) eigentlich einsetzt/benötigt, da - wie oben geschildert - das Ganze auch OHNE mod_fastcgi mit einem Wrapper-Script läuft.

Diese Wrapper-Geschichte ist eigentlich nur eine Krücke, um eine PHP-Instanz hochzuziehen, die dann per fcgi angesprochen wird.

Um das mit dem FastCGI "richtig" auszunutzen, kann man Folgendes machen:

Per spawn-fcgi (aus den Ports) wird ein "PHP-Daemon" gestartet, der dann per mod_fcgi/fastcgi direkt und ohne Wrapper-Script über einen Socket angesprochen werden kann. In den neueren PHP-Version kann man php auch gleich selbst als fcgi-Server starten, ist glaube ich aber noch experimentell.

Dann braucht man nur noch

AddHandler php5-fastcgi .php
FastCgiExternalServer /webroot/http -host 192.168.1.10:9000

Vorteile:
- fix definierte Prozess-Anzahl = kein Apache-Prozess-Wildwuchs mehr unter Last
- kein Modul-Overhead = Apache wird sehr viel schlanker + muss keine php-Modul-Instanzen pro Prozess hochstarten
- es können mehrere Webserver das gleiche PHP-Backend parallel benutzen, z.B. apache, nginx, lighttp usw.
- man kann den "PHP-Dienst" auf einen extra Server auslagern

Viele behaupten, dass diese FastCGI-Geschichte langsam sei, aber kann ich nicht bestätigen. Ich finde sogar, dass diese "echte" FastCGI-PHP-Server mindestens genauso schnell (wenn nicht schneller) läuft als ein Apache, der jedesmal alles forken muss.