Welche Sprache soll ich nehmen?
-
Kann man das Thema nicht schließen? Es nervt so langsam!
Mittlerweile hat auch der letzte verstanden, dass es unterschiedliche Meinungen zu diversen Programmiersprachen gibt.
LG
-
hmmz|off schrieb:
Kann man das Thema nicht schließen? Es nervt so langsam!
Mittlerweile hat auch der letzte verstanden, dass es unterschiedliche Meinungen zu diversen Programmiersprachen gibt.
LG
Klar. Es führt aber kein Weg an HTML und CSS vorbei. Bevor man da nicht
sattelfest ist, ist die Serverseite zweitrangig. PHP ist mir zu lahm, ich
nehme halt etwas anderes.
-
nman schrieb:
Die Ausführungsgeschwindigkeit der Sprache wird für die Performance einer Webanwendung in der realen Welt kaum je in irgendeiner Form einen Flaschenhals darstellen...
und wo verbringt man die meißte zeit? ich dachte, wenn man nicht den teufel raus cached am ehesten in der scriptsprache, oder?
-
Na ja, Dein Script erstellt irgendwie HTML/CSS/JS-Output.
Der wird dann in handliche Häppchen verteilt und dem Apatsche in die
Hand gedrückt. Der sagt dann dem bösen Internet (vdLeyen) "hier, tu das
man dem x.x.x.x irgendwie senden". Dann spastelen sich BND, NSA und wen's
sonst nch interessiert durch die Häppchen, schauen nach ob es was mit
Taliban oder KiPo ist und wenn das Häppchen dann im Browser landet, soll
er sinnvoll damit etwas anfangen und es auf der lahmen Gurke anzeigen.Sorgen um die Laufzeit des Script muß man sich erst bei heftigen Datenmengen
oder richtig großen Portalen machen ...Was man als CGI nimmt ist eigentlich wurscht, ich nehme halt C.
-
Scheppertreiber schrieb:
...soll er sinnvoll damit etwas anfangen und es auf der lahmen Gurke anzeigen...
stimmt! hätte ich fast vergessen, die anzeige braucht natürlich idr. am meisten. aber das ist client und nicht server
p.s. evtl. können wir ja mal zusammen an einer kleinen c-webapp basteln, davon träum ich schon ewig
-
Ich habe ein große Webapp in C ...
-
ja, apache hab ich auch schon drauf :p
-
_-- schrieb:
ja, apache hab ich auch schon drauf :p
Dann bring ihm bei, daß er *.exe (bei Windos) als CGI-Programm behandeln soll.
Der Input (das CGI) kommt über stdin, der Output geht nach stdout.Das Primitiv-Helloworld sieht dann in etwa so aus:
printf( "\n<p>Hello World !</p>");
-
Scheppertreiber schrieb:
Sorgen um die Laufzeit des Script muß man sich erst bei heftigen Datenmengen
oder richtig großen Portalen machen ...Nein. Was wichtig ist ist die Skalierbarkeit. Alles andere ist ziemlich uninteressant.
Was man als CGI nimmt ist eigentlich wurscht, ich nehme halt C.
CGI skaliert absolut beschissen. Man sollte immer als Modul des Webservers laufen.
Deshalb ist PHP auch nicht langsam. Ruby zB hat langsamere Ausführungsgeschwindigkeit als PHP - das ist aber kein Problem weil die Performance mit der Skalierbarkeit des Frameworks steht und fällt.
-
Shade Of Mine schrieb:
Scheppertreiber schrieb:
Sorgen um die Laufzeit des Script muß man sich erst bei heftigen Datenmengen
oder richtig großen Portalen machen ...Nein. Was wichtig ist ist die Skalierbarkeit. Alles andere ist ziemlich uninteressant.
du hast also so viel geld, dass es dir egal ist, ob du zur beantwortung von 100 anfragen 10 server brauchst? skalieren natürlich super horizontal
Shade Of Mine schrieb:
Was man als CGI nimmt ist eigentlich wurscht, ich nehme halt C.
CGI skaliert absolut beschissen. Man sollte immer als Modul des Webservers laufen.
CGI skaliert überhaupt nicht, sondern die an das interface gekoppelte software...
Shade Of Mine schrieb:
Deshalb ist PHP auch nicht langsam.
doch! und schlimmer wirds wenn teenie "hacker" dann auch noch alles selbst in php nachbauen müssen, weil die mitgelieferten funktionen nicht taugen
-
CGI skaliert absolut beschissen. Man sollte immer als Modul des Webservers laufen.
Deshalb ist PHP auch nicht langsam. Ruby zB hat langsamere Ausführungsgeschwindigkeit als PHP - das ist aber kein Problem weil die Performance mit der Skalierbarkeit des Frameworks steht und fällt.
Nein. Wie immer hängt es davon ab ...
Du bringst da einiges durcheinander:
* CGI ist die Schnittstelle, dort laufen die gesendeten Parameter und
die Antwort des Programms drüber.
* die Ausführung ist im aufgerufenen CGI-Programm, dort ist PHP
nicht "schnell".Sollte ich mal an einen Punkt kommen, wo CGI der Flaschenhals ist, schreibe
ich den Kram zum Apache-Modul um, nicht vorher.Das Wichtigste ist, sattelfest im HTML/CSS zu sein, also semantisch korrektes
HTML und sinnvolles CGI. Das ergibt automatisch kurzes HTML, also auch kurze
Verarbeitungs- und Transferzeiten (das Stylesheet etc werden ja nur einmal
übertragen und laufen dann aus dem Chache).Ergo Hirn statt dubioser Frameworks und blabla-Projekten.
-
_-- schrieb:
du hast also so viel geld, dass es dir egal ist, ob du zur beantwortung von 100 anfragen 10 server brauchst? skalieren natürlich super horizontal
Symfonie skaliert zB ein paar Ecken besser als Rails.
PHP ist durch das Sandbox Prinzip prinzipiell ideal für Skalierung geeignet.Niemand redet in diesem Bereich von Sprachen: man redet nur von Frameworks. Denn wie schnell eine Funktion ausgeführt wird ist irrelevant wenn es darum geht viele Anfragen du parallel bearbeiten kannst. Natürlich ist es praktisch wenn eine Funktion schneller ausgeführt wird - aber die essentielle Frage ist: wieviel Arbeit macht das Framework denn? Denn wenn du 100% langsamer ausführst, aber nur 30% der Arbeit machst - bist du immer noch schneller.
Deshalb: Niemand interessiert sich in diesem Bereich für Sprachen. Man redet nur von Frameworks.
CGI skaliert überhaupt nicht, sondern die an das interface gekoppelte software...
Die Software die hinter dem CGI steckt ist uninteressant wenn du CGI verwendest (naja, nicht ganz, aber du kannst so oder so keine große Menge an Anfragen beantworten).
doch! und schlimmer wirds wenn teenie "hacker" dann auch noch alles selbst in php nachbauen müssen, weil die mitgelieferten funktionen nicht taugen
Irrelevant. Unfähige Leute gibt es überall.
Merkt man zB hier. Die Sprache ist nämlich komplett irrelevant. Was zählt ist das Framework. Denn dort liegt die Aufgabe der Skalierung.
-
es gibt einfach sprachen die vom design langsam sind. da kann dein framework auch nichts mehr machen. wenn dann auch noch 10ksloc framework-code durch den interpreter wandern müssen seh sich schwarz (ja man kann auch da mit tools wieder cachen).
merkst, was man da alles cachen muß, damit bischen speed rein kommt?
-
_-- schrieb:
es gibt einfach sprachen die vom design langsam sind. da kann dein framework auch nichts mehr machen.
Tja, die reale Welt sieht halt anders aus. Da kommt es nämlich auf den praktischen Nutzen an. Und symfony skaliert zB ziemlich gut. Deshalb wird das verwendet.
Ideologie ist da wenig interessant.
-
Mir kam letztens auch eine interessante Idee.
Wie steht es mit C++ und CGI. Ist das perfomant, und kommt man damit gut zurecht?
-
Pikkolini schrieb:
Mir kam letztens auch eine interessante Idee.
Wie steht es mit C++ und CGI. Ist das perfomant, und kommt man damit gut zurecht?CGI ist nicht tragbar. FastCGI geht, aber wenn C++ dann als Appserver wie zB tntnet. Ich wuerde aber einfach ASP.NET nehmen oder Java.
C++ als CGI oder FastCGI macht keinen Sinn. Da muss die Anforderung schon enorm speziell sein dass sich das lohnt.
-
Wie sieht es denn mit Java aus? Ich kenn da nur das Google Webtoolkit, und was braucht man da überhaupt für einen Server?
-
GWT hat nichts mit serverseitiger Software zu tun
