Cgi/FastCgi vs PHP
-
Hallo Leute,
Ich hätte mal an euch die Frage:
Ob C welches mit CGI/FastCgi als WebSprache genutzt wird langsammer ist als PHP
unter einem ganznormalen Webserver wie Apache.
Hier geht es einfach nur um durchschnitt und nicht um esoterische Problemstellungen
-
Andersherum gefragt: was macht dich glauben, dass es Situationen geben könnte, in denen C + FastCGI langsamer als PHP ist?
-
Die Frage ist nicht ob ich Glaube. Eigentlich wollte ich gerne wissen.
Alle Test die ich gemacht haben, hatten ehrlich gesagt keinen signifikanten Unterschied gezeigt. Jedoch habe ich in paar Foren gelesen das FastCgi/Cgi langsammer sein soll als PHP.
Da z.B Apache so konfiguriert werden kann das nicht ständig neue Prozesse gestartet werden um PHP zu interpretieren. Wo hingegen bei FastCgi/Cgi für jeden Nutzer der Prozess gestartet werden muss.Nur bis jetzt habe ich ehrlich gesagt, wenn man den Test Optimistisch deutet festgestellt das C mit FastCgi um paar takte schneller war. Nur das muss nix bedeuten.
Ich habe für mich das so interpretiert mein Prozess hatte halt ein bisschen mehr Glück gehabt.Aber trotzdem die Frage gibt es eine klare Antwort auf meine Eigangsfrage ?
-
PHP kann doch auch über FastCGI genutzt werden. Für Apache gibt es zwar mod_php. Aber auch FastCGI (und CGI?) ist möglich. Und ein wichtiger Unterschied zwischen FastCGI und CGI ist gerade der, dass man nicht immer einen neuen Prozess starten muss. Aber ich denke mal, dass das heutzutage auch nicht mehr so wild ist. Auf Linuxsystemen ist das Prozessstarten mittlerweile extrem schnell.
Bei Prozessen hat man nämlich den Vorteil der Separation. Macht ein Prozess misst, dann wird nur dieser beendet. Bei FastCGI kann es passieren, dass das ganze Backend gekillt wird, weil nur eine Anfrage misst macht und bei mod_php uä kann dann sogar der ganze Webserver dran glauben. (Aber heutzutage nehmen die meisten ohnehin lieber lighttpd oder nginx anstelle Apache).
Ob es sich nun aber lohnt Webanwendungen in C zu schreiben ist ein anderes Thema. Das Nadelöhr ist ja in der Regel die Datenbank.
Wobei ich natürlich ohnehin auf PHP verzichten und lieber eine sinnvolle Sprache, wie Python, Ruby, Perl, Erlang etc. benutzen würde.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Webzeugs verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Zunächst muss man zwischen CGI und FastCGI unterscheiden. CGI ist laaaangsam, da es für jeden Request einen neuen Prozess startet. FastCGI tut genau das nicht. Daher ist es deutlich schneller.
Bei einem minimalen Hello-World-Beispiel, den ich mal gemacht habe, war PHP aber noch schneller als FastCGI. Mit echten Applikationen kann das aber anders aussehen. Es kommt immer darauf an, wie viel man wirklich macht. Wenn ich eine rechenintensive Applikation habe, dann wird C PHP immer ausstechen. Und wenn die Rechenzeit lang genug ist, fällt selbst das starten eines Prozesses nicht so sehr ins Gewicht. Von daher kann unter Umständen selbst CGI mit C schneller sein als PHP.
Also kurz gesagt: es kommt darauf an.
-
@tntnet
PHP als mod_php ist vielleicht schneller. Aber wie gesagt, weil das direkt in den Server gepackt ist und bei Sicherheitsproblemen (kommen regelmäßig bei PHP vor und werden teilweise äußerst peinlich gefixt), ist dann der ganze Server angreifbar bzw. bei einem DOS nimmt es den ganzen Server mit. Bei FastCGI kann man dem Server ja idR noch sagen, wie er den FastCGI Prozess neustarten soll, wenn der Socket nicht mehr da ist und bei CGI hat man so ein Problem gar nicht. Stürzt bei CGI der CGI-Prozess ab, dann beeinflusst das die anderen nicht. Und auch ein amoklaufender Prozess, der versucht x gig Speicher zu fressen, wird einfach vom OOM-Killer beendet.Wie schauen denn aktuelle Messungen aus? Wieviel langsamer ist CGI im Vergleich zu FastCGI?
Wobei ich bei den Diskussionen auch ganz interessant finde, was Betreiber von echt großen Seiten sagen: Neue Webserver sind überhaupt kein Problem aufzusetzen. Richtig aufwendig wird das nur, wenn man einen weiteren Datenbankserver braucht. Daher sollte man wohl lieber die Zeit darein investieren, dass man sinnvoll mit der Datenbank umgeht.
-
rüdiger schrieb:
@tntnet
PHP als mod_php ist vielleicht schneller. Aber wie gesagt, weil das direkt in den Server gepackt ist und bei Sicherheitsproblemen (kommen regelmäßig bei PHP vor und werden teilweise äußerst peinlich gefixt), ist dann der ganze Server angreifbar bzw. bei einem DOS nimmt es den ganzen Server mit. Bei FastCGI kann man dem Server ja idR noch sagen, wie er den FastCGI Prozess neustarten soll, wenn der Socket nicht mehr da ist und bei CGI hat man so ein Problem gar nicht. Stürzt bei CGI der CGI-Prozess ab, dann beeinflusst das die anderen nicht. Und auch ein amoklaufender Prozess, der versucht x gig Speicher zu fressen, wird einfach vom OOM-Killer beendet.Wie schauen denn aktuelle Messungen aus? Wieviel langsamer ist CGI im Vergleich zu FastCGI?
Wobei ich bei den Diskussionen auch ganz interessant finde, was Betreiber von echt großen Seiten sagen: Neue Webserver sind überhaupt kein Problem aufzusetzen. Richtig aufwendig wird das nur, wenn man einen weiteren Datenbankserver braucht. Daher sollte man wohl lieber die Zeit darein investieren, dass man sinnvoll mit der Datenbank umgeht.
Die Sicherheit ist eine vielfältige Sache. Wenn ich eine beispielsweise SQL-Injection habe, ist das egal, ob meine Webapplikation in-process oder out-of-process läuft. Auch wenn meine Applikation aufgrund eines Implementierungsfehlers Daten zur Verfügung stellt, die es nicht zeigen sollte, ist das auch egal, wie die Applikation läuft. Du sprichst also nur von einem möglichen Angriffsszenario, bei dem der eigentliche Webapplikationsserver fehlerhaft ist.
PHP-Applikationen sind sicher auch deswegen angreifbar, da sie häufig von Anfängern geschrieben werden. Diese bauen beispielsweise gerne mal SQL-Statements von Hand auf und ignorieren dabei sowohl korrektes escaping, statt prepared Statements zu verwenden.
Ich habe lange keine Messungen mehr gemacht, aber damals lag CGI mit Perl bei 28 #/s, CGI mit C bei 75 #/s, FastCGI mit C bei 750#/s und PHP bei 1200#/s. Statische Seiten mit Apache lagen bei 3000#/s. Dynamische Seiten mit Tntnet bei 3300#/s. JSP lag irgendwo zwischen PHP und statischen Seiten.
Die Messungen haben allerdings nur eine Hello-World-Applikation getestet, bei dem der initiale Overhead besonders zum Tragen kommt. Habe ich eine Applikation, die substantiell etwas macht, sieht die Sache sicher anders aus. Da kann denke ich mal selbst CGI mit C doch einiges aufholen.
-
oh doch ein Faktor 10 bei CGIs. Aber wie du sagst, wird das bei echten Anwendungen wohl anders ausschauen.
Ich meinte Sicherheitslücken konkret auf den PHP Interpreter und mod_php bezogen. Die Sicherheitslücken, die die ganzen Programmierer dann noch machen, sind ja eher in der Programmlogik oder - wie du bereits gesagt hast - in der Datenbank. Wobei das natürlich auch indirekt die Folge von PHP ist.