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)
Wie wär's mit node.js? Da muss auch nicht bei jedem Aufruf der Code neu übersetzt werden und man hat auch keinen CGI-Flaschenhals.
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 :-)))))))))))))))))
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.