PHP-Umfrage
-
Der Durchschnitt schrieb:
da in Wirklichkeit eine neue Klasse erstellt wird mit der gegebenen Superklasse
Wie lange dauert das? Gregor hat mal erzählt, dass ein Aufruf der Compiler-API 900 Millisekunden gedauert hat, was ganz klar unakzeptabel langsam ist.
-
Badestrand schrieb:
r0nny schrieb:
dann kann man auch gleich eines der genialen frameworks in ruby oder python nehmen
die sind flotter als php und für die gewöhnlichen 08/15 seiten muss man keine zeile sql schreiben, injections werden automatisch verhindert, und man hat eine sauere trennung von modellen, opertationen und darstellung
warum also php noch ändern - einfach nur was einsetzen, das nicht mist ist
Soweit ich weiß, ist Ruby (On Rails) aber wesentlich langsamer als PHP und auch wesentlich RAM-& CPU-intensiver.
Ohne FastCGI (oder so ähnlich?) soll da nix gehen, ausprobiert hab ichs aber noch nicht
kannst du es auch beweisen?
Ausserdem kann man immer einen fetteren Server kaufen
-
Mr. N schrieb:
Der Durchschnitt schrieb:
da in Wirklichkeit eine neue Klasse erstellt wird mit der gegebenen Superklasse
Wie lange dauert das? Gregor hat mal erzählt, dass ein Aufruf der Compiler-API 900 Millisekunden gedauert hat, was ganz klar unakzeptabel langsam ist.
Ich weiß noch, dass das vor 2 Jahren auf jeden Fall ein Problem war, zumindestens wenn man ständig Proxies neu erstellen wollte. Wie das heute aussieht, weiß ich ehrlich gesagt nicht so genau, aber ansich ist das, selbst wenn es heute noch so ist, kein so großes Problem, wie du es darstellst. Letztendlich brauchst du ja nur ein Proxy-Objekt pro Klasse und dieses kannst du dann benutzen um die Aufrüfe an weitere "Proxies" zu delegieren. Dadurch hast du maximal etwas längere Startzeiten je nachdem wieviele Klassen man für die Proxies erstellen muss. Soweit ich weiß, hat es beispielsweise Google beim Google Guice Framework ähnlich implementiert, da die ja auch CGLIB verwenden.
-
phlox81 schrieb:
kannst du es auch beweisen?
Ausserdem kann man immer einen fetteren Server kaufenIch hab mich einfach auf (mehrere) Erfahrungsberichte verlassen, die User gepostet haben
Ich meine auch gelesen zu haben, dass die RoR-Leute selber empfehlen, FastCGI zu nehmen, und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.Man kann über PHP sagen, was man will, aber immerhin ist es bewährt und praxistauglich :p
-
Badestrand schrieb:
und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.
naja, lighttpd mit PHP über FastCGI performt besser als Apache mit mod_php... Also sehr sehr relativ deine Feststellung über FastCGI...
-
Der Durchschnitt schrieb:
Dadurch hast du maximal etwas längere Startzeiten je nachdem wieviele Klassen man für die Proxies erstellen muss.
Naja wenn man 500 Klassen erstellen will ist das sicher nicht so praktikabel. Oder?
Badestrand schrieb:
Man kann über PHP sagen, was man will, aber immerhin ist es bewährt und praxistauglich
Bewährt und praxistauglich hieße für mich auch: Wenige Sicherheitslücken.
-
jedenfalls haben die meisten 'ich hasse php' angekreuzt.
was die PHP-hasser wohl für die webprogrammmierung nehmen würden?
JSP? ASP.NET oder was anderes?
-
Mr. N schrieb:
Der Durchschnitt schrieb:
Dadurch hast du maximal etwas längere Startzeiten je nachdem wieviele Klassen man für die Proxies erstellen muss.
Naja wenn man 500 Klassen erstellen will ist das sicher nicht so praktikabel. Oder?
Wenn wir von dem Fall ausgehen, dass ein Projekt 500 Proxyklassen direkt beim Start benötigt, dann denke ich, dass es angemessen ist zu behaupten: Das ist mit ziemlicher Sicherheit keine 1-Tier Anwendung, die nur auf dem Desktop läuft. Realistischer ist wohl eher, dass ein Web- oder gar Applicationserver verwendet wird und hierbei ist es ja für den Benutzer nicht so wichtig wie lange die Startzeiten sind, da er diese nie abwarten muss. Zusätzlich erlauben ja viele Applicationserver auch noch Hot-Deployment womit sich Performanceeinbußen beim Starten noch weiter relativieren.
was die PHP-hasser wohl für die webprogrammmierung nehmen würden?
JSP? ASP.NET oder was anderes?Obwohl ich eigentlich eingefleischter Java-Programmierer bin, würde ich für kleinere Projekte, die ich ansonsten womöglicherweise auch in PHP implementieren würde, zu ASP.NET greifen, sofern es die Infrastruktur eben erlaubt. Man müsste schon beinahe absichtlich entsprechende Lücken einbauen, damit z.B. SQL Injection oder ähnliches möglich wäre. Entwicklungszeiten sind auch phänomenal kurz und was Microsoft da mit ASP.NET AJAX produziert hat spricht ja wirklich für sich. ASP.NET ist eben nicht ASP, da darf man Vorurteile auf keinen Fall mitschleppen.
-
pale dog schrieb:
jedenfalls haben die meisten 'ich hasse php' angekreuzt.
was die PHP-hasser wohl für die webprogrammmierung nehmen würden?
JSP? ASP.NET oder was anderes?Perl mit mod_perl
einfach genial - genial einfach
und sicherer
und ich liebe einfach solche aufrufe wie com am[y]... wieter oben beschrieben...
-
rüdiger schrieb:
Badestrand schrieb:
und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.
naja, lighttpd mit PHP über FastCGI performt besser als Apache mit mod_php... Also sehr sehr relativ deine Feststellung über FastCGI...
Ganz ehrlich Rüdiger, ich kenne mich mit der Thematik kaum aus; vor ein oder zwei Wochen wollte ich mir nur mal Ruby On Rails anschauen, hab ein wenig damit herumgespielt und mir halt Erfahrungsberichte durchgelesen.
Das waren die Informationen, die ich erhalten hab und ich "glaube" daran, jedenfalls im Groben.
Was ich davon noch im Kopf hab, ist, dass "normales" CGI irgendwelchen Krams bei Bedarf lädt und ausführt. FastCGI hingegen behält den Krams die ganze Zeit über im Arbeitsspeicher und verwendet aus irgendwelchen Gründen auch mehr CPU als Normal-CGI. Ich weiß, dass diese "Informationen" sehr sehr vage sind, ich hab aber nunmal keine Lust, mich wegen der Diskussion tiefer in die Thematik einzuarbeiten.
Jedenfalls soll laut einiger Quellen RoR mit normalem CGI sehr langsam laufen, der Server sollte deshalb FastCGI verwenden, was aber mehr Ressourcen beansprucht. Für gegenläufige Aussagen will ich Beweise
Mr. N schrieb:
Badestrand schrieb:
Man kann über PHP sagen, was man will, aber immerhin ist es bewährt und praxistauglich
Bewährt und praxistauglich hieße für mich auch: Wenige Sicherheitslücken.
Das ist Ansichtssache, Windows finde ich auch "bewährt und praxistauglich", strotzt(e) aber auch nicht vor Sicherheit.
-
Mr. N schrieb:
DEvent schrieb:
Ist ja mit C++ genauso.
Ich höre wesentlich seltener von sicherheitskritischen Bugs in GCC, glibc und libstdc++ als in PHP. Also nein, ist nicht genauso.
Naja, wieviel GCC, glibc und libstdc++ wird den in Servern für die generierung von HTML-Seiten verwendet?
Das hört sich allerdings interessant an:
... und für die gewöhnlichen 08/15 seiten muss man keine zeile sql schreiben, injections werden automatisch verhindert, und man hat eine sauere trennung von modellen, opertationen und darstellung
Achja btw, der Grund wieso ich mich noch nicht mit RonR beschäftigt habe ist eigentlich der: Ruby ist eine mächtige OO-Sprache, aber irgendwie ist Ruby bei Web-Anwendung wie mit Kanonnen auf Spatzen zu schießen. Relativiert sich das vielleicht mit der Größe des Web-Projektes, aber trotzdem. Für einfache Einsatzzwecke sollte man auch ein einfaches Werkzeug benutzen, und da hat eben php Vorteile.
Na, in nächster Zeit werde ich paar Bücher zu RonR lesen, dann sprechen wir uns wieder.
-
Badestrand schrieb:
rüdiger schrieb:
Badestrand schrieb:
und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.
naja, lighttpd mit PHP über FastCGI performt besser als Apache mit mod_php... Also sehr sehr relativ deine Feststellung über FastCGI...
Ganz ehrlich Rüdiger, ich kenne mich mit der Thematik kaum aus; vor ein oder zwei Wochen wollte ich mir nur mal Ruby On Rails anschauen, hab ein wenig damit herumgespielt und mir halt Erfahrungsberichte durchgelesen.
Das waren die Informationen, die ich erhalten hab und ich "glaube" daran, jedenfalls im Groben.
Was ich davon noch im Kopf hab, ist, dass "normales" CGI irgendwelchen Krams bei Bedarf lädt und ausführt. FastCGI hingegen behält den Krams die ganze Zeit über im Arbeitsspeicher und verwendet aus irgendwelchen Gründen auch mehr CPU als Normal-CGI. Ich weiß, dass diese "Informationen" sehr sehr vage sind, ich hab aber nunmal keine Lust, mich wegen der Diskussion tiefer in die Thematik einzuarbeiten.
Jedenfalls soll laut einiger Quellen RoR mit normalem CGI sehr langsam laufen, der Server sollte deshalb FastCGI verwenden, was aber mehr Ressourcen beansprucht. Für gegenläufige Aussagen will ich BeweiseErst nicht auskennen und dann Forderungen stellen, ja das haben wir gerne. :p
Beweise du lieber erstmal, dass mod_php keine Ressourcen braucht...
Badestrand schrieb:
Mr. N schrieb:
Badestrand schrieb:
Man kann über PHP sagen, was man will, aber immerhin ist es bewährt und praxistauglich
Bewährt und praxistauglich hieße für mich auch: Wenige Sicherheitslücken.
Das ist Ansichtssache, Windows finde ich auch "bewährt und praxistauglich", strotzt(e) aber auch nicht vor Sicherheit.
PHP ist noch eine Größenordnung schlimmer als Windows.
-
Badestrand schrieb:
rüdiger schrieb:
Badestrand schrieb:
und dass FastCGI mehr RAM und CPU braucht, steht relativ fest.
naja, lighttpd mit PHP über FastCGI performt besser als Apache mit mod_php... Also sehr sehr relativ deine Feststellung über FastCGI...
Ganz ehrlich Rüdiger, ich kenne mich mit der Thematik kaum aus; vor ein oder zwei Wochen wollte ich mir nur mal Ruby On Rails anschauen, hab ein wenig damit herumgespielt und mir halt Erfahrungsberichte durchgelesen.
Das waren die Informationen, die ich erhalten hab und ich "glaube" daran, jedenfalls im Groben.
Was ich davon noch im Kopf hab, ist, dass "normales" CGI irgendwelchen Krams bei Bedarf lädt und ausführt. FastCGI hingegen behält den Krams die ganze Zeit über im Arbeitsspeicher und verwendet aus irgendwelchen Gründen auch mehr CPU als Normal-CGI. Ich weiß, dass diese "Informationen" sehr sehr vage sind, ich hab aber nunmal keine Lust, mich wegen der Diskussion tiefer in die Thematik einzuarbeiten.
Jedenfalls soll laut einiger Quellen RoR mit normalem CGI sehr langsam laufen, der Server sollte deshalb FastCGI verwenden, was aber mehr Ressourcen beansprucht. Für gegenläufige Aussagen will ich BeweiseÄh, du kennst dich wirklich nicht aus. Informiere dich doch einfach was CGI und FastCGI sind :p CGI ist immer sehr langsam, da dort ein Prozess pro Aufruf angelegt wird. Der httpd startet für jede Anfrage einfach ein Programm (das CGI-Programm). Bei FastCGI wird ein Programm gestartet und die Kommunikation zwischen httpd/FastCGI erfolgt über ein (UNIX-)Socket oder Pipe (ok, FastCGI kann auch wesentlich mehr als CGI, aber das ist für die Diskussion eh irrelevant). Ein mod_* wird direkt in den Server-Prozess eingebunden.
Was sich nun daraus ergibt, kannst du dir ja vermutlich selbst herleiten. Und wie gesagt: lighttpd kann PHP schneller über FastCGI, als Apache über mod_php!
Naja, wieviel GCC, glibc und libstdc++ wird den in Servern für die generierung von HTML-Seiten verwendet?
Ziemlich viel oder womit sind wohl PHP, Python, Ruby, Apache etc. geschrieben?
Außerdem hat das eine wohl nichts mit dem anderen zu tun Ruby ist eine mächtige OO-Sprache, aber irgendwie ist Ruby bei Web-Anwendung wie mit Kanonnen auf Spatzen zu schießen. Relativiert sich das vielleicht mit der Größe des Web-Projektes, aber trotzdem. Für einfache Einsatzzwecke sollte man auch ein einfaches Werkzeug benutzen, und da hat eben php Vorteile.
Tut mir leid, aber das scheint nur eine esotherische Gefühlsregung von dir zu sein.
-
Google verwendet teilweise C++ für die eigenen Webseiten.
-
Mr. N schrieb:
Google verwendet teilweise C++ für die eigenen Webseiten.
ja, als sie angefangen haben, galt C++ als die beste und fortschrittlichste programmiersprache.
...aber ich hab' irgendwo gelesen, dass sie damit mittlerweile recht unglücklich sind.btw: ebay-interne software ist bzw. war mal, zum grössten teil in c++/MFC/winapi gestrickt.
-
pale dog schrieb:
Mr. N schrieb:
Google verwendet teilweise C++ für die eigenen Webseiten.
ja, als sie angefangen haben, galt C++ als die beste und fortschrittlichste programmiersprache.
Außerdem würde niemand mit PHP das Internet indexieren.
-
Mr. N schrieb:
btw: ebay-interne software ist bzw. war mal, zum grössten teil in c++/MFC/winapi gestrickt.
War. Seit geraumer Zeit ist ebay "Java-powered":
http://java.com/en/ebay7.jsp?_trksid=m37tfa
-
wenn hier so viele sagen, dass php scheiße ist, warum ist dieses forum dann mit php programmiert?
Mr. B
-
Mr. B schrieb:
wenn hier so viele sagen, dass php scheiße ist, warum ist dieses forum dann mit php programmiert?
phpBB2 war vor 5 Jahren "das Beste" und Alternativen wie CGI, Java, ASP bzw. ASP.NET waren nur für große Geschäftsseiten möglich und natürlich recht kostspielig.
Heute ist die Zeit anders
ASP.NET Server kosten sogut wie nichts mehr und der Technikstand hat sich erheblich geändert.Außerdem ist eine Migration dieses Forums auf andere Programmier-/Script-Sprachen eine Mammutaufgabe.
So sieht das aus
-
tja... dann bleibt marc++us wohl nichts anderes übrig, als an php gestaltend so mitzuwirken, dass es irgendwann wieder die nr. 1 unter den programmiersprachen ist, die für solche zwecke benötigt werden.