PHP oder SSI - was ist schneller ?

[Dennis]

Hi Christoph,

Sorry, dass ich erst jetzt wieder dazu komme, hier zu schreiben - aber ich war in den letzten Tagen ziemlich beschäftigt, sodass dieser Thread etwas in Vergessenheit geraten ist ;-)

aber FastCGI bietet einen guten Ersatz, was hast du dagegen?

Ich habe gar nichts dagegen, mir ist nur nicht bekannt, daß das eben von seriösen Hostern so gehandhabt wird.

Nun - soweit ich weiß, ist diese Alternative ja auch nicht so gerade das Älteste, was es gibt. Abgesehen davon: Occuris verwendet diese Methode ;-) Und ich bin eh immer der Meinung, dass nicht immer das was alle machen das beste ist.

Ich halte PHP über FastCGI in Verbindung mit suExec für eine der besten und saubersten Lösungen was eine Multi-User Umgebung mit diversen Scriptsprachen angeht.

Bittesehr. Meine bisherigen Erfahrungen erlauben mir eine solche Aussage nicht. Was auch daran liegt, daß ich "FastCGI in Verbindung mit suExec" nur einmal ganz flüchtig angekuckt, aber bisher nicht wirklich ausprobiert/getestet habe.

Auch wenn deine Erfahrungen aufgrund längeren daseins in den Sachen sicherlich größer sind, als die meiningen, so halte ich es doch für sinnvoll, suExec o.ä. einzusetzen - hierbei wirst du mir vermutlich auch noch zustimmen.
Doch wenn du PHP als ein Apache Modul verwendest, kannst du es (AFAIK) nur mit suPHP und nicht mit suExec kontrollieren - d.h. für den Administrator, dass er ein Modul mehr pflegen muss. Jedoch lassen sich die Aufgaben von suPHP auch prima mit suExec realisieren, wie z.B. dieses Howto (für Debian) zeigt.

Außerdem lassen sich nur über (Fast)CGI mehrere PHP Versionen gleichzeitig betreiben, sowie z.B. 1und1 PHP4 und PHP5 gleichzeitig anbietet (.php und .php5 Dateien).

Das nun wieder halte ich für einen Irrtum, und wenn ich mich recht erinnere, müßte das Forumsarchiv auch ein paar Texte von Christoph Zurnieden zu dieser Frage der Parallelinstallation unterschiedlicher PHP-Versionen hergeben.

Ja, aber immer läuft es darauf hinaus, dass bei zwei parallel installieren PHP Versionen mindestens eine davon über CGI eingebunden wird - ich erinnere mich da z.B. an diesen Thread wo dedlfix sogar versucht hat, den PHP Quellcode entsprechend zu modifizieren, was aber auch misslungen ist.

Ich habe jetzt im Archiv auch nichts entsprechendes gefunden - eine Suche nach "Christoph Zurnieden php zwei versionen" gab keine erfolgreichen Treffer.

Ein "großer" Hoster wie 1und1 wird ja wohl keine Probleme haben, für seine unterschiedlichen Webhosting-Angebote auch unterschiedliche PHP-Versionen (sofern überhaupt gestattet) einzurichten. Wir wissen bloß nicht, ob der OP seinen Internetauftritt bei 1und1 hosten läßt.

Nicht für unterschiedliche Webangebote! Da ich auch bei 1und1 bin, habe ich es gerade noch mal getestet - *.php Dateien werden mit PHP 4.4.1 geparst, *.php5 Dateien mit PHP 5.0.5.
Äußerst interessant ist, dass bei beiden Versionen in der phpinfo() steht:
  ServerAPI  CGI
Da scheint also tatsächlich PHP über CGI zu laufen ...

Ich halte das eh für zu fest "hinterlegt" - das sieht man z.B. daran, das sich bei der Modul Version von PHP der Mime Type nicht anpassen lässt.

Ups? Wie meinst du das? Selbst bei einer "Modulvariante" unter einem auf WindowsXP laufenden Apache kann ich problemlos MIME-Typen "anpassen" bzw. über eine .htacces erlauben/verbieten.

Wo kannst du denn das was anpassen? Bei mir unter WinXP sieht die Einbindung von PHP4 als Apache Modul so aus:

LoadFile "C:/Server/xampp/php/php4/php4ts.dll"  
LoadModule php4_module "C:/Server/xampp/php/php4/php4apache2.dll"  
AddType application/x-httpd-php .php .php3 .php4

Wo kann ich hier denn das application/x-httpd-php ändern? Und das ist ja gerade, was ich meine - das application/x-httpd-php scheint vom Modul vorgegeben zu werden und ich habe keinen Einfluss darauf.

Gut, FilesMatch wäre die korrekte[tm] Alternative dazu - Files mit ~ bewirkt aber selbiges.

Nö. Es sei denn, der angesprochene Apache hat schon ein paar Jahresringe angesetzt und versteht <FilesMatch> gleich gar nicht.

Hierzu hat sich Sven ja schon geäußert.

MfG, Dennis.