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

[dock]

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

- persistente Datenbankverbindungen
- Apache spezifische Funktionen (zzgl. Servervariablen aus Apache Modulen wie z.B. HTTP Auth)


Wer weiß noch mehr? Wir versuchen gerade abzuwägen, welche Funktionseinbußen ein User haben wird, wenn wir auf PHP via fcgi umstellen.

[hotzi]

Ich überlege auch gerade, statt mod_php su_php zu implementieren, damit das mit den Rechten auf per php hochgeladene Files stimmt.

Mich würden auch weitere potentielle Nachteile interessieren.

[dtdesign]

Performance.

Ein reines CGI-Binary (ohne fastcgi/fcgi oder sonstigem) muss bei jedem Aufruf eines PHP-Scripts über den Webserver extra in den Speicher geladen werden (um die 400kb) und nach Ende des Script wieder aus selbigem entfernt werden.

Ergo verbrät man ständig zusätzliche Leistung, da bei vielen, nacheinander ankommenden Anfragen, immer PHP erst in den Speicher geladen werden muss, bevor das Script ausgeführt wird. Bei mod_php residiert PHP immer im Speicher.

Als Alternative kann ich fastcgi empfehlen, dass nahezu die Performance von mod_php erreicht, dazu aber via suexec mehr Sicherheit bietet. Zudem kann ein PHP als FastCGI-Binary eine frei definierbare Menge an Instanzen von PHP im Speicher belassen, so dass fast das selbe Verhalten von mod_php erreicht wird.

PS: Dieser Beitrag stellt meinen Erkentnisstand bzw. meine Erfahrungen dar. Ich kann nicht 100% für die Richtigkeit garantieren, aber 99% sollten drin sein ;)

Gruß
dtdesign

[hotzi]

Woran erkannt man eigentlich in einer phpinfo(); welches Interface genau benutzt wir? bei ServerApi steht ja nur was vonCGI/FastCGI

[Roger Wilco]

Woran erkannt man eigentlich in einer phpinfo(); welches Interface genau benutzt wir? bei ServerApi steht ja nur was vonCGI/FastCGI

Den Unterschied zwischen CGI und FastCGI siehst du nicht. Wenn mod_php genutzt wird, steht unter Server API "Apache".

[hotzi]

Ich spiele gerade ein bissel damit rum und lese alte Docs.

Wenn ich das richtig lese, ist also fcgi deutlich schneller, als cgi oder su_php. Für fcgi soll man aber ein fcgi bin von php brauchen. Ich will das ganze aber gern nur mit debian paketen bauen.

Hat jemand nen Tipp?

... ich google derweil mal weiter

[Anonymous]

Ich spiele gerade ein bissel damit rum und lese alte Docs.
Wenn ich das richtig lese, ist also fcgi deutlich schneller, als cgi oder su_php.

su_php ist nichts anderes als ein Apache Modul, das PHP via CGI über den SuExec2 Wrapper einbindet.
Es ist also egal ob Du manuell PHP als CGI mit Suexec2 Wrapper einsetzt oder "einfach nur su_PHP".

Der Untschied zwischen fcgi und cgi ist, das nicht für jede Anfrage die PHP Binary neugeladen wird, sondern eine Weile im Speicher verbleibt. Das macht fcgi dann schneller als cgi.


Was mich aber auch interessiert:

Welche Funktionen sind nur bei mod_php verfügbar? Es soll neben der Performance auch ein weitaus geringeres Funktionspektrum bei der CGI SAPI geben.
Hat jemand eine Liste? Irgendwie weiß nämlich keiner so genau bescheid… alle reden über Performance, aber keiner denkt an eventuell wichtige Funktionen, die dann im cgi Binary nicht mehr enthalten sind!

[hotzi]

Nach dem was ich bisher gelesen habe, ist das Wurst für meine zwecke, ich brauchs nicht, dass der Apache seinen Basic Auth User per Variable an PHP übergibt.

Das "Problem" welches ich habe: suphp ist kein akt, aber ich würde schon gern die maximale performance haben, da ich Confixx benutze, werde ich da aber eh ein Problemchen bekommen, da es mir dann zahlreiche nicht verwendbare Parameter in die Configs ballert.

[Roger Wilco]

su_php ist nichts anderes als ein Apache Modul, das PHP via CGI über den SuExec2 Wrapper einbindet.

Das stimmt nicht ganz. SuPHP bringt einen eigenen Wrapper mit, der sich im Gegensatz zu SuExec(2) die Konfiguration erst zur Laufzeit aus /etc/suphp.conf holt.

Welche Funktionen sind nur bei mod_php verfügbar?

http://de3.php.net/de/apache

Alle anderen sind vorhanden, wenn die entsprechende Erweiterung installiert ist (entweder shared oder statisch im PHP-Binary). Selbst die oben genannten persistenten Datenbankverbindungen (ich vermute es waren mysql_pconnect und Konsorten waren gemeint) sind vorhanden. Man muss sich nur vor Augen führen, dass die persistente Verbindung eben nur solange lebt, wie der PHP-Interpreter läuft. Bei Einsatz von PHP über CGI also genau einen Request lang.

[hotzi]

Hm es wird verwirrend, je mehr ich lese.

Mich würde wirklich interessieren, wie groß der Performance Unterschied zwischen mod_php und suphp + PHp5 bei Debian Etch im Schnitt ist.

Ich werde das jetzt mal testweise aufsetzen und ein paar ab-Läufe machen...

[theomega]

Meiner Erfarhung nach ist der Unterschied riesig, wenn du ordentlich Last auf den Seiten hast auf jeden Fall spürbar.

Was zu berücksichtigen ist: Authentification via HTTP-Access geht nicht, so kann der phpmyadmin nicht wie gehabt genutzt werden (muss auf cookie-based authentification umgestellt werden)

[compositiv]

Das "Problem" welches ich habe: suphp ist kein akt, aber ich würde schon gern die maximale performance haben, da ich Confixx benutze, werde ich da aber eh ein Problemchen bekommen, da es mir dann zahlreiche nicht verwendbare Parameter in die Configs ballert.

Confixx läuft einwandfrei mit suphp, erst recht seid der Version 3.2.1

[hotzi]

Ja, aber suphp hat aber eben wohl keine maximale Performance, da hakts ja

[cirox]

Ich will das ganze aber gern nur mit debian paketen bauen.

Dann mach das doch und zieh dir die Debian Sourcen. Änderungen kannst Du am rules File machen.

[dtdesign]

[...]Was zu berücksichtigen ist: Authentification via HTTP-Access geht nicht, so kann der phpmyadmin nicht wie gehabt genutzt werden (muss auf cookie-based authentification umgestellt werden)

Das ist doch Käse. Ich verwende einen Apache2 mit suPHP/PHP5-CGI und kann traumhaft die HTTP-Authenitifizierung aktivieren und es funktioniert einwandfrei. phpMyAdmin mogelt mir auch keine ähnlichen Cookies unter.

Mit den Debian Sarge 3.1 Paketen und entsprechend PHP5-CGI via dotdeb.org läuft alles perfekt (abgesehen von der Performance, weshalb ich bei Etch auf fcgi umsteigen möchte).

Gruß
dtdesign

[hotzi]

Was nicht geht, ist das Übergeben der Basic Auth Infos an PHP.

[theomega]

[...]Was zu berücksichtigen ist: Authentification via HTTP-Access geht nicht, so kann der phpmyadmin nicht wie gehabt genutzt werden (muss auf cookie-based authentification umgestellt werden)

Das ist doch Käse. Ich verwende einen Apache2 mit suPHP/PHP5-CGI und kann traumhaft die HTTP-Authenitifizierung aktivieren und es funktioniert einwandfrei. phpMyAdmin mogelt mir auch keine ähnlichen Cookies unter.

Mit den Debian Sarge 3.1 Paketen und entsprechend PHP5-CGI via dotdeb.org läuft alles perfekt (abgesehen von der Performance, weshalb ich bei Etch auf fcgi umsteigen möchte).

Gruß
dtdesign

Aufpassen bevor du hier Sachen als Käste bezeichnest, die Doku gibt mir nämlich recht:
http://www.php.net/manual/en/features.http-auth.php

The HTTP Authentication hooks in PHP are only available when it is running as an Apache module and is hence not available in the CGI version.

Was du geändert hast weiß ich nicht, zumindest unterstützt die Konstelation PHP->CGI->Apache Out-Of-The-Box ziemlich sicher keine HTTP-Authentification über die o.a. Befehle.

[hotzi]

Kann es sein, dass ihr was durcheinanderschmeisst?

[Roger Wilco]

Was du geändert hast weiß ich nicht, zumindest unterstützt die Konstelation PHP->CGI->Apache Out-Of-The-Box ziemlich sicher keine HTTP-Authentification über die o.a. Befehle.

Mit SuPHP (das ja auch das CGI-Binary benutzt) schon. Allerdings hast du (bzw. die Doku) bei mod_cgi[d] und FastCGI natürlich Recht.

[dtdesign]

In der Tat habe ich es nie ohne einen Wrapper ausprobiert. PHP lief bei mir anfangs als Apache2-Modul und später nur über suPHP. Offensichtlich kann suPHP diese Informationen an PHP weitergeben, weshalb es zum Erfolg führt.

Ich hatte explizit meine Konfiguration/Pakete aufgelistet, darum hatten wir beide Recht ;)

Gruß
dtdesign

[kase]

Wenn ich das richtig lese, ist also fcgi deutlich schneller, als cgi oder su_php. Für fcgi soll man aber ein fcgi bin von php brauchen. Ich will das ganze aber gern nur mit debian paketen bauen.

su_php bzw php als cgi ist DEUTLICH langsamer als mod_php, ich denke mindestens um den Faktor 2-3. fastcgi hingegen kommt nahezu an die Performance von mod_php ran, hat allerdings einen etwas höheren Konfigurationsaufwand.

Debian Pakete neu bauen brauchst du nicht. Sowohl das mod_fcgid Modul für den Apache gibt es als Paket, als auch das PHP Binary mit fastcgi, das ist nämlich das selbe wie das CGI, da heutzutage alle CGI Binarys auch FastCGI können. Vorraussetzung ist aber Debian ETCH, bei Sarge muss man einiges selbst baun oder massiv Backports installieren.

[hotzi]

Also dass suphp einen auf fcgi macht geht nicht?

Wegen Confixx muss ich nämlich suphp hernehmen, oder modphp...

[kase]

Nein, suphp ist ein Apache Modul für php als CGI, wenn du php als FCGI nehmen willst, dann brauchst du ein fastcgi Modul, wie mod_fcgid oder mod_fastcgi.

Ich kann mir aber nicht vorstellen, dass Confixx nicht mit mod_fcgid oder ähnlichem funktioniert, aber da müssten sich mal ein paar äußern, die Confixx benutzen :)

[adjustman]

ist DEUTLICH langsamer als mod_php, ich denke mindestens um den Faktor 2-3

kann man diese Einbuße durch z.Bsp. eAccelerator wieder wettmachen?

[dtdesign]

Nein, da das Cachen immer nur für jeweils exakt eine Datei funktioniert. Genau die, die du aufrufst. Sobald PHP wieder aus dem Speicher verschwindet, was bei CGI der Fall ist, wars das mit dem schönen Cache.

Gruß
dtdesign