Standardfrage.... mit welcher sprache online???

Scheppertreiber

Das nenne ich echtes Mitleid

Vielleicht schreckt die Warnung des BSI "Leute, Hände wech vom IE ..."
mal einige IE6-Muffel auf. Vielleicht ist das so wie der, selbstverständlich
nur unnötiges Geld kostenden Datensicherung: Es muß einmal richtig weh tun

PRIEST

Man traut sich zuwenig

Scheppertreiber schrieb:

Ich mache das alles in C, andere nehmen PHP, Ruby etc.

C ist toll, ich mag C, aber für dynamisch erzeugte webseiten ist C doch viel zu umständlich. nimm besser PHP, ist C-ähnlich (== kaum lernaufwand, wenn man schon C kann) und bringt alles mit, was sich der webprogrammierer wünscht.

Scheppertreiber

;fricky schrieb:

Scheppertreiber schrieb:

Ich mache das alles in C, andere nehmen PHP, Ruby etc.

C ist toll, ich mag C, aber für dynamisch erzeugte webseiten ist C doch viel zu umständlich. nimm besser PHP, ist C-ähnlich (== kaum lernaufwand, wenn man schon C kann) und bringt alles mit, was sich der webprogrammierer wünscht.

Ich habe PHP auch ausprobiert. Es ist schlicht zu lahm und zu unflexibel,
jeder Scipt-Kiddie bohrt Dir darim herum. Lieber gleich das Original

Scheppertreiber schrieb:

Ich habe PHP auch ausprobiert. Es ist schlicht zu lahm und zu unflexibel

nicht so schnell aufgeben. PHP selbst ist in C geschrieben, es ist im prinzip eine skriptsprache, die die interaktion zwischen libraries regelt (die meisten davon sind auch in C geschrieben), also lahm ist da nix, unflexibel sowieso nicht. du solltest nur keine rechenintensiven algorithmen in PHP implementieren. wenn du was spezielles brauchst, kannst du auch in C geschriebene .exen von PHP aus aufrufen und deren output im skript verarbeiten, oder winapi-funktionen direkt aufrufen, usw. (das erfordert natürlich eine windows-box als server). kurz: man hat alle möglichkeiten, meistens reicht aber das, was PHP sowieso schon anbietet.

Scheppertreiber

Sorry, es geht echt um Performance. Und etwas größere Datenmengen.
Es ist ja alles scriptgesteuert, halt interpretiert durch ein C-Programm.
PHP kann das einfach nicht.

branleb

HTML5 gibt afaik es ebenso als XML spezifizierte Version namens XHTML5.

Und persöhnlich muss ich sagen, ich fand die Ansätze und Ideen hinter XHTML2 gut.
Und nur weil einige (leider viele) verbohrte Köpfe auf dem alten crap bestehen und nicht modernisieren und dazulernen wollen, ist es nun tot.

Leider

Scheppertreiber schrieb:

Sorry, es geht echt um Performance. Und etwas größere Datenmengen.
Es ist ja alles scriptgesteuert, halt interpretiert durch ein C-Programm.
PHP kann das einfach nicht.

doch. wie gesagt, du kannst zeitkritischen code in .exen, .dll, oder .so auslagern und nebenbei alle annehmlichkeiten von PHP geniessen. der bremsklotz ist sowieso das netzwerk, selten der server-code. hier taucht z.b. manchmal so'n freak mit seinen 'c++ server pages' auf, der postuliert, dass schneller seitenaufbau/reaktion/whatever nur möglich ist, wenn jeglicher code direkt von der CPU des servers ausgeführt wird, was aber absoluter bullshit ist.

PRIEST

branleb schrieb:

HTML5 gibt afaik es ebenso als XML spezifizierte Version namens XHTML5.

Und persöhnlich muss ich sagen, ich fand die Ansätze und Ideen hinter XHTML2 gut.
Und nur weil einige (leider viele) verbohrte Köpfe auf dem alten crap bestehen und nicht modernisieren und dazulernen wollen, ist es nun tot.

Leider

ähm ... ja

Scheppertreiber

Hi Fricky,

klar ist das Bullshit, es hat ja mit dem HTML oder der Auslieferung nichts zu tun.

C ist für mich einfacher wie PHP, warum sollte ich mischen (mit der ganzen Zickerei
die ich mir dann ans Bein binde) ?.

So habe ich Programme mit eingebettetem SQLite, Vorteile:

* keine Installation
* keine ständigen Updates und Patches
* serverseitig sehr schnell

In der Firma haben wir eine 10 MBit-Anbindung und 10 aktive Server. 2 Leute kümmern
sich um die Teile. 10mal PHP und mySQL hegen und pflegen ? Die erschlagen mich

tntnet

;fricky schrieb:

Scheppertreiber schrieb:

Sorry, es geht echt um Performance. Und etwas größere Datenmengen.
Es ist ja alles scriptgesteuert, halt interpretiert durch ein C-Programm.
PHP kann das einfach nicht.

doch. wie gesagt, du kannst zeitkritischen code in .exen, .dll, oder .so auslagern und nebenbei alle annehmlichkeiten von PHP geniessen. der bremsklotz ist sowieso das netzwerk, selten der server-code. hier taucht z.b. manchmal so'n freak mit seinen 'c++ server pages' auf, der postuliert, dass schneller seitenaufbau/reaktion/whatever nur möglich ist, wenn jeglicher code direkt von der CPU des servers ausgeführt wird, was aber absoluter bullshit ist.

Genau: nur Tntnet ist das wahre. Du sollst nichts anderes verwenden als Tntnet. Sonst bekommst Du es mit überflüssigen CPU-Zyklen zu tun :p .

Unix-Tom

Auch wenn ich jetzt ASPNET verwende.

Habe mal einen Chat mit c geschrieben. Ich war begeistert wie schnell das ging gegenüber PHP.
Ist aber auch schon 6 Jahre her. Kann sein das sich da nun einiges bei PHP geändert hat

Scheppertreiber

Ich behaupte ja auch nicht, PHP sei schlecht.

Klar ist, das ein Interpreter immer langsamer wie 'was Kompiliertes
ist. C ist nun mal sehr schnell.

Ich habe generell so wenig wie möglich exe-Files auf dem Server. Im
Prinzip reicht genau eins das parametrisiert wird. Vorteil: Mir pfuscht
keiner im Code herum und ein Update ist zwingend komplett (da wird nicht
mal eben eine Kleinigkeit vergessen).

PRIEST

Scheppertreiber schrieb:

Ich behaupte ja auch nicht, PHP sei schlecht.

Klar ist, das ein Interpreter immer langsamer wie 'was Kompiliertes
ist. C ist nun mal sehr schnell.

Ich habe generell so wenig wie möglich exe-Files auf dem Server. Im
Prinzip reicht genau eins das parametrisiert wird. Vorteil: Mir pfuscht
keiner im Code herum und ein Update ist zwingend komplett (da wird nicht
mal eben eine Kleinigkeit vergessen).

kennst du da ne kleine einführungs page wo ich mir das mal anschauen kann? Hab mich damit noch nie so 100%ig beschäftigt. Eher hörensagen und Theo.

Bin jetzt einfach schon an PHP gewöhnt

Scheppertreiber

Geht eigentlich recht einfach:

---

Server:

Apache etwas unterschieben das er *.exe als CGI akzeptiert

AddType text/html .exe
AddOutputFilter INCLUDES .htm
AddOutputFilter INCLUDES .exe

---

CGI-Programm (primitiv-Beispiel):

#include <stdio.h>

        main (argc, argv)
        int     argc;
        char    *argv[];
{

        printf( "\n<html><head></head><body>Hello Wörld</body></html>");
}

Dann aufrufen, zB "http://myserver.tld/test.exe"

PRIEST

Achso ja.. ich wollte ja mal ein browsergame schreiben und hab mir überlegt für dem server ne kleine engine zu basteln.

tntnet

Ich wundere mich ein wenig, dass Du damit eine gute Performance bekommst. Ich habe verschiedene Techniken auf meiner Linux-Kiste getestet. Da hat C als CGI aufgerufen eher schlecht abgeschnitten. Das Problem ist, dass bei CGI immer ein Prozess gestartet werden muss. Ein kleines Programm ist da mit PHP wesentlich schneller, als CGI/C. PHP hat den Vorteil, dass es im Apache-Prozess sofort zur Verfügung steht. Erst bei komplexeren Seiten kommen die Vorteile von C zur Geltung.

Bei Tntnet verhält es sich anders, da die Webapplikationen da bei einem Request keine weiteren Prozesse gestartet werden müssen.

Nur so zur Grössenordnung: Auf meinem Rechner bei einer Hello-World-Anwendung hatte ich mit CGI/C 75#/s, mit PHP 2800#/s und mit Tntnet 9800#/s. Je komplexer die Seiten werden, desto langsamer wird natürlich PHP im Vergleich zu den anderen beiden.

Scheppertreiber

Klar. Ich habe da ziemlich komplexe Sachen laufen.

SideWinder

Wie schneidet fastcgi ab?

MfG SideWinder

tntnet

SideWinder schrieb:

Wie schneidet fastcgi ab?

MfG SideWinder

fastcgi habe ich im gleichen Test mit etwa 750#/s gemessen.