Hallo,
ich habe hier ein bereits älteres cgi-Prgramm ("/cgi/anwendung.exe") zur
Visuliasierung von Messdaten aus einer Datenbank über einen Webbrowser,
das auf dem Microsoft Internet Information Server läuft und per default
("index.html") aufgerufen wird.
Das Programm ist in C geschrieben und streamt je nach den gewählten
Optionen den passenden html-Code direkt in den Browser.
Damit ist es auch dynamisch, weil es sich je nach den angeklickten
Optionen (Schaltflächen) selbst mit den entsprechenden Parametern wieder
aufruft.
Jetzt stellt sich Frage nach einer Erneuerung und mich würde
interessieren, welche Lösung ihr für so eine Anwendung unter aktuellen
Gesichtspunkten empfehlen würdet (wieder C, C++, Java, Perl, ...) ?
Die Anwendung sollte möglichst ressourcenschonend und schnell laufen,
mit einer freien Entwicklungsumgebung programmiert werden, zukünftig gut
weiterzuentwickeln sein und natürlich Datenbankzugriffe beherrschen.
Danke !
In den größeren Unternehmen, in denen ich bereits gearbeitet habe wurde
zum einen das Zend Framework, also letztendlich PHP genutzt um richtig
große Anwendungen zu programmieren... damit wurde dann letztendlich eine
Model-View-Control Struktur angewendet, wodurch die Programme sehr gut
überarbeitet werden können.
Zum Anderen wird Ruby mit "Ruby on Rails" verwendet. Dazu kann ich nicht
viel sagen, aber es macht einen sehr guten Eindruck in hinsichtlich der
Erlernbarkeit der Sprache.
Christian
PHP und Schnelligkeit passen jetzt nicht so ganz zueinander. Der
komplette Code muss bei jedem Aufruf neu übersetzt werden (Ja ich weiß
es gibt Bytecode-Spielerein, aber naja). Ich arbeite selbst mit PHP,
aber hardwarenahe Sprachen wie C/C++ sind mit Sicherheit um einiges
schneller. Wenn du schon mit C arbeiten kannst, dann bleib dabei.
Schneller wird höchstens nur noch in Assembler.
Die Frage verleitet ehrlich gesagt ein wenig zum trollen, denn jeder
kann jetzt hier seine Lieblingssprache reinschreiben, mit mehr oder
weniger stichhaltigen Argumenten für oder wider eine spezielle
Implementierung.
In der Praxis sieht es eigentlich immer so aus, dass Du einen Kompromiss
zwischen der Programmierarbeit und dem Ressourcenverbrauch eingehen
musst. Die Anwendung in C zu schreiben ist ziemlich Richtung
Ressourcenverbrauch optimiert.
Wenn du es neu schreiben willst, ist die wichtige Frage eigentlich
danach, welche Sprachen und Systeme Du bereits beherrscht und wieviel
Arbeit Du in die Neuentwicklung stecken willst. Wenn du eine neue
Sprache verwenden willst, musst du mit Sicherheit alles neu schreiben.
Wenn du bei C bleibst, kannst du vielleicht Teile des alten übernehmen.
Je nach Umfang des Ganzen kann sich das lohnen oder nicht.
Letztlich ist es immer die Frage: wieviel kostet Deine Arbeitszeit und
was kostet der neue Rechner, wenn der alte nicht mehr schnell genug ist.
Eine optimale Sprache oder Entwicklungsumgebung würde ich angesichts
der Frage nicht empfehlen, denn wenn Du z.B. bereits der C-Guru bist,
wirst Du da wahrscheinlich mit weniger Arbeit eine Lösung entwickeln
können als wenn Du zusätzlich noch etwas komplett neues lernen musst,
bevor Du mit der eigentlichen Arbeit anfängst.
> Jetzt stellt sich Frage nach einer Erneuerung
Du meinst dasselbe noch mal schlechter zu schreiben ?
> C++, Java, Perl
sind aus Resourcensicht natürlich viel schlechter aös
die bestehende Lösung.
Der eizige Nachteil der CGI basierten Lösung ist,
daß anwendung.exe bei jedem Aufruf neu geladen wird.
Falls also die Antwortzeit und nicht der Hauptspeicher
auf dem Server die zu schonende Resource ist, wäre
eine Lösung besser, die als DLL immer im Speicher hängt.
Ansonsten ist man ja gerne für mehr Flexibilität, also
eine Vorlage in die vom Programm beim Abruf nur die
Daten eingefüllt werden. Die Vorlage kann in HTML sein.
Ob die Daten als Felder darin auftuchen oder komplexer
sind, hast du nicht geschrieben.
Früher gab es im VisualStudio einen Wizard für IIS dll's. Da gibt es
dann ein Funktion( oder war das schon C++, i don't remember), in die die
Applikationslogik rein kam, fast wie CGI. Und wer die bestehende Version
in C versteht, der bekommt auch das hin. Nur die ganz alte CD's muß man
halt noch haben ...
MaWin schrieb:> Der eizige Nachteil der CGI basierten Lösung ist,> daß anwendung.exe bei jedem Aufruf neu geladen wird.
Das passiert bei PHP auch ...
Es geht wunderbar in C. Flaschenhals ist halt das CGI (da könnte
man durch fastCGI noch einiges herausholen). PHP ist im Vergleich
zu C grottenlahm, fehleranfällig und halt ein Interpreter.
(Ich habe ein größeres System unter Apache und C laufen)
wenn eh schon ein Windows eingesetzt wird, dann würde ich mir mal
ASP.NET anschauen. Man kann ganz einfache seiten erzeugen (vergleichbar
mit PHP) und wenn es etwas mehr sein soll richtige Anwendungen. Diese
können dann auch Threads ausführen. Globale persistente Veriabeln und
ähnliches.
Bei PHP gefällt mit nicht, das es bei jeden Seitenaufruf immer bei 0
losgeht, da müssen erstmal die Session eingelesen werden
datenbankverbindungen (teilweise) neu aufgebaut werden usw. Bei .NET
bleibt das alles im RAM erhalten und damit sind kleine aufrufe (z.b.
Ajax ) viel schneller.
Es gibt sehr viele Erweiterungen wie z.b. für Imageerzeugung.
Und wenn es sein muss, läuft es sogar unter linux mit mono.
Peter II schrieb:> Bei PHP gefällt mit nicht, das es bei jeden Seitenaufruf immer bei 0> losgeht, da müssen erstmal die Session eingelesen werden> datenbankverbindungen (teilweise) neu aufgebaut werden usw. Bei .NET> bleibt das alles im RAM erhalten und damit sind kleine aufrufe (z.b.> Ajax ) viel schneller.
Liegt doch eh alles im Cache.
Ich arbeite auch viel mit Ajax, es läuft alles über eine exe
die die Aufrufe decodiert und ausführt. Flaschenhals ist die
Auslieferung über den Webserver und die Leitung, die Lade- und
Startzeiten der exe merkst Du nicht (Erfahrungswerte - kein
Blabla).
"Die Anwendung sollte möglichst ressourcenschonend und schnell laufen,
mit einer freien Entwicklungsumgebung programmiert werden, zukünftig gut
weiterzuentwickeln sein und natürlich Datenbankzugriffe beherrschen."
Naja, definiere möglichst Ressourcenschonend? Der IIS ist ja nun auch
nicht gerade für geringen Resourcenverbrauch bekannt...
Ich würde für die Anwendung ja eine Websprache wie PHP nehmen. Damit
sind Datenbankzugriffe etc. aufjedenfall einfacher umzusetzen als in
C++. Auch die sonstige Entwicklung dürfte wesentlich flotter
vorangehen(auch wenn man natürlich ziemlich viel Kacke damit anstellen
kann, wenn man sich nicht auskennt)
A. B. schrieb:> Ich würde für die Anwendung ja eine Websprache wie PHP nehmen. Damit> sind Datenbankzugriffe etc. aufjedenfall einfacher umzusetzen als in> C++. Auch die sonstige Entwicklung dürfte wesentlich flotter> vorangehen(auch wenn man natürlich ziemlich viel Kacke damit anstellen> kann, wenn man sich nicht auskennt)
Was soll das sein, eine "Websprache" ?
Datenbankzugriffe in C sind bei zB SQLite genauso einfach.
Die "Entwicklungszeit" richtet sich nach dem Können des
Entwicklers, nicht der Sprache.
Joachim Drechsel schrieb:> Ich arbeite auch viel mit Ajax, es läuft alles über eine exe> die die Aufrufe decodiert und ausführt.
auch mit Datenbankanbindung?
denn die anmeldung an den DB dauert auch ein paar ms und kosten im
Datenbankserver resourcen. diese kann man sich sparen wenn die anwendung
persistent ist.
Das starten einer EXE kosten schon viele resourcen, das ist der
schlechteste weg soetwas umzusetzen. Da ist isapi schon ein stück
besser, da wird die anwendung nur einmal geladen und dann jeweils nur
ein Thread gestartet.
Das man bei soetwas keinen unteschied merkt wen nur ein paar 100 request
pro s ankommen ist klar. Aber es gibt auch server wo es ein paar 1000
sein können und da macht es sich auf jeden Fall bemerkbar.
Peter II schrieb:> auch mit Datenbankanbindung?
SQLite
> denn die anmeldung an den DB dauert auch ein paar ms und kosten im> Datenbankserver resourcen. diese kann man sich sparen wenn die anwendung> persistent ist.
Klar. Wenn's mal klemmt mache ich für den Indianer ein Modul.
> Das starten einer EXE kosten schon viele resourcen, das ist der> schlechteste weg soetwas umzusetzen. Da ist isapi schon ein stück> besser, da wird die anwendung nur einmal geladen und dann jeweils nur> ein Thread gestartet.
Es ist der einfachste Weg.
> Das man bei soetwas keinen unteschied merkt wen nur ein paar 100 request> pro s ankommen ist klar. Aber es gibt auch server wo es ein paar 1000> sein können und da macht es sich auf jeden Fall bemerkbar.
Es sind noch nicht einmal 100 / sec. Eher weniger wie 10 ;-)
Dafür hat das Programm ordentlich zu tun (Onlie-Archiv mit größeren
Datenbeständen > 1 TB pa). Dazu Zugriffsrechte die ich Dank der
Kreavitität der erlauchten Kundschaft schon nicht mehr über eine
Datenbank gebacke bekomme. Vom Import und der Datenanlyse bis
zur Erzeugung von PDF ist alles drin. Das Programm erzeugt auch
das HTML/CSS und JavaScipt.
Ich hatte das mal aus Neugier mit PHP probiert, es ist zu lahm.
Joachim Drechsel schrieb:> Was soll das sein, eine "Websprache" ?>> Datenbankzugriffe in C sind bei zB SQLite genauso einfach.>> Die "Entwicklungszeit" richtet sich nach dem Können des> Entwicklers, nicht der Sprache.
Nunja...ein Programmiersprache die aus dem Dunstkreis des WWW entstanden
ist. Wie z.B. eben PHP.
Und die Entwicklungszeit richtet sich absolut nach der
Programmiersprache, je nach dem was diese dem Programmierer schon an
Standardaufgaben abnimmt...da ist es wurscht wie gut der Programmierer
ist.
Klar kannst du das Auslesen deiner Webformulare auch in ASM
programmieren...das es mit PHP schneller geht, weil es genau für diesen
Zweck ausgelegt ist, wirst du hoffentlich nicht bestreiten.
A. B. schrieb:> Klar kannst du das Auslesen deiner Webformulare auch in ASM> programmieren...das es mit PHP schneller geht, weil es genau für diesen> Zweck ausgelegt ist, wirst du hoffentlich nicht bestreiten.
Schlechtes Beispiel weil zu trivial ... ;)
> Klar kannst du das Auslesen deiner Webformulare auch in ASM> programmieren...das es mit PHP schneller geht
Das Erstellen des Programms mag zwar schneller gehen,
aber die Ablaufzeit/Speicherbedarf der WebAnfrage sicher nicht.
omg...da haben wir wieder die Superoptimierer. Hatte jetzt jemand
ernsthaft das Gefühl, das der Threadersteller das letzte Quentchen an
Geschwindigkeit benötigt???
Aber klar...bei 08/15 Anwendungen macht es DEN Unterschied ob die
Anzeige der Seite 50ms oder 100ms dauert. Und natürlich hat hier jeder
Seiten mit 1000 Request pro Sekunde am laufen, die endlich mal so
richtig Dampf brauchen.
> Vom Import und der Datenanlyse bis> zur Erzeugung von PDF ist alles drin. Das Programm erzeugt auch> das HTML/CSS und JavaScipt.
Was ist das denn für eine Anwendung, das dein Serverprogramm dynamisch
JavaScript erzeugen muss?!
A. B. schrieb:> Was ist das denn für eine Anwendung, das dein Serverprogramm dynamisch> JavaScript erzeugen muss?!
Online-Archiv mit einer Prise Workflow, ausgelegt für große
Datenmengen. Seit ca 8 Jahren online.
ich würde (in diesem fall) vermutlich auch eine ISAPI DLL machen..
da sollte man den code zu 95% beibehalten können
oder alternativ eine "haupt" exe (als Service/Dienst) der immer läuft
und die "arbeit" macht (Datenbankverbindungen öffen hält usw. )
und eine kleine/schmale cgi exe die sich nur damit "verbindet" ..
Joachim Drechsel schrieb:> Was soll das sein, eine "Websprache" ?
Auch wenn Du PHP und Konsorten nicht magst, wirst Du doch wohl sehr
genau wissen, was mit dem Begriff gemeint ist. Also bitte nicht trollen.
Mark Brandis schrieb:> Joachim Drechsel schrieb:>> Was soll das sein, eine "Websprache" ?>> Auch wenn Du PHP und Konsorten nicht magst, wirst Du doch wohl sehr> genau wissen, was mit dem Begriff gemeint ist. Also bitte nicht trollen.
Lies nochmal was ich geschrieben hatte ...
interrupt schrieb:> Jetzt stellt sich Frage nach einer Erneuerung und mich würde> interessieren, welche Lösung ihr für so eine Anwendung unter aktuellen> Gesichtspunkten empfehlen würdet (wieder C, C++, Java, Perl, ...) ?
jeder wird dir das empfehlen was er kennt und was er selbst zum laufen
bekommt - resourcen werden imho erst dann beachtet wenn sie knapp werden
und man was merkt.
ICH würds in php oder perl machen, also das daten abholen aus der db,
und dann entweder ein externes tool (gnuplot?) zum bild erzeugen
benutzen oder schauen ob php/perl(cpan) sowas nativ kann.
schau dir, jenachdem was für daten du sammelst und visualisierst, mal
"rrdtool" an :)
Joachim Drechsel schrieb:> Lies nochmal was ich geschrieben hatte ...
Dann zeig mir doch mal beispielhaften Code, wie man in C oder C++ ganz
schnell und einfach auf eine MySQL-Datenbank zugreifen kann. Die
"Websprachen" können das nämlich.
Joachim Drechsel schrieb:>> Der eizige Nachteil der CGI basierten Lösung ist,>> daß anwendung.exe bei jedem Aufruf neu geladen wird.>> Das passiert bei PHP auch ...
PHP ist oft im Apache als Modul drin, wird dann also nicht extern
geladen, und mit Zeugs wie Zend bewaffnet wird auch das ausgeführte
Script nicht jedes Mal neu geladen und übersetzt.
Klassische CGIs sind mir unter all dem installierten Kram (den andere
entwickeln) schon lange nicht mehr untergekommen. Hauptsächlich PHP,
einiges in serverseitigem Java. Komischerweise ist das Java-Zeugs immer
das Ressouren-hungrigste.
Joachim Drechsel schrieb:> A. B. schrieb:>> Was ist das denn für eine Anwendung, das dein Serverprogramm dynamisch>> JavaScript erzeugen muss?!>> Online-Archiv mit einer Prise Workflow, ausgelegt für große> Datenmengen. Seit ca 8 Jahren online.
Aha...trotzdem ein merkwürdiges Konstrukt, das man sein JS dynamisch
erzeugt...oder ist das nur ungenau ausgedrückt?
bist du eigentlich im xhtmlforum.de unterwegs? scheppertreiber kommt mir
irgendwie bekannt vor.
Udn so trivial find ich mein Beispiel im Kontext dessen was der
Threadersteller da gepostet hat übrigens nicht...irgendwelche HTML
Seiten generieren, Buttons auswerten...das hört sich nach Standardkram
an...da kann man sich das Leben mit PHP einfach machen, oder man fängt
in C an Strings zu parsen...also ich weiss was mir mehr Spass machen
würde, aber das kann ja jeder tun und lassen wie ihm beliebt
A. B. schrieb:> bist du eigentlich im xhtmlforum.de unterwegs? scheppertreiber kommt mir> irgendwie bekannt vor.
Klar :-)))
Das Forentreffen ist auch bei mir :-)))))))))))))))))
