nicht angemeldet
Geschwindigkeit/was passiert im Detail
Hallo!
Ich diskutiere gerade mit ein paar Leuten eine Serverproblematik aus.
- Version 1
- NT-Server
- Microsoft IIS
- MSQL-Datenbank
- ASP-Seiten
- eigene DLL, die bestimmte Befehle an die Datenbank weiterleitet
- Version 2
- Linux (allg. Unix)- Server
- Informix-Datenbank
- Perl-Module (entsprechend der DLL von Version 1)
Es gibt Leute, die meinen, weil ja die DLL im Speicher gehalten wird, die Perlprogrämmchen aber jedesmal starten müssen (ist das das wirklich so???), wäre die Geschwindigkeit bei Version 1 weitaus höher.
Ich bin mir nicht sicher, ob das stimmt, für mich gibt es einen klaren Vorteil bei Version 2: die Entwicklungsgeschwindigkeit. Zudem SEHE ich einfach, daß Version 1 auch Geschwindigkeitsprobleme hat. Zudem habe ich eine andere Frage: Wie wird die Connectivity in Version 2 hergestellt? Wie sind die Zeitverältnisse, d.h. Aufruf des Perlprogrammes, Ansprechen der Datenbank, usw.
Gibt es dazu Erfahrungen, Meinungen?
Danke!!
Reiner
-
Hallo!
Es gibt Leute, die meinen, weil ja die DLL im Speicher gehalten wird, die Perlprogrämmchen aber jedesmal starten müssen (ist das das wirklich so???), wäre die Geschwindigkeit bei Version 1 weitaus höher.
Wenn man von den Basis-Installationen ausgeht, dann ist dies so.
Aber jeder der etwas von seinem Webserver versteht, weiß auch, dass es Server-Module gibt,
die eben dafür sorgen, daß die Perl-Skripten auch dort im Speicher bleiben.
Und schon ist der Vorteil weg.Ich bin mir nicht sicher, ob das stimmt, für mich gibt es einen klaren Vorteil bei Version 2: die Entwicklungsgeschwindigkeit. Zudem SEHE ich einfach, daß Version 1 auch Geschwindigkeitsprobleme hat. Zudem habe ich eine andere Frage: Wie wird die Connectivity in Version 2 hergestellt? Wie sind die Zeitverältnisse, d.h. Aufruf des Perlprogrammes, Ansprechen der Datenbank, usw.
Gibt es dazu Erfahrungen, Meinungen?
Nun, "Entwicklungsgeschwindigkeit" ist fuer mich das Keyword: ASP ist eine neue "Sprache", die nicht auf die Entwicklungsgeschichte von Perl und somit dem Sprachumfang zurückblicken kann.
Zudem ist Perl im Gegensatz zu ASP weitgehend Plattformunabhängig, während ASP eigentlich nur für Windows gemacht wurde und gerade erst eine UnixVersion raus ist...Weiteres Plus von Perl: Es ist verbreitet und (was von vielen, die nur CGI sehen unterschätzt wird:) es hat sich für Administrationsskripten auf Unix/Linux ebenfalls gut durchgesetzt.
Ähnliches gilt übrigens auch im Vergleich Perl vs. PHP.
Man muß halt sehen, das PHP und ASP recht "neu" sind und deswegen da noch ein Hype drum gemacht wird, wie damals bei JavaScript.
Ciao,
Wolfgang-
Hallo Wolfgang,
Wenn man von den Basis-Installationen ausgeht, dann ist dies so.
Aber jeder der etwas von seinem Webserver versteht, weiß auch, dass es Server-Module gibt,
die eben dafür sorgen, daß die Perl-Skripten auch dort im Speicher bleiben.
Und schon ist der Vorteil weg.DLL ist native-Code ..... Perl wird interpretiert. Geschwindigkeitsvorteil könnte also knapp bleiben :-)
Nun, "Entwicklungsgeschwindigkeit" ist fuer mich das Keyword: ASP ist eine neue "Sprache", die nicht auf die Entwicklungsgeschichte von Perl und somit dem Sprachumfang zurückblicken kann.
Für viele Probleme braucht man gar nicht die Mächtigkeit von Perl und da ist ASP u.U. schneller erstellt. Somal bei ASP der Code da ist, wo er hingehört. Nämlich in der HTML-Seite und nicht irgendwas externes, was die Sache bloß unübersichtlich macht (kommt natürlich auch darauf an, was und wie man es macht).
Zudem ist Perl im Gegensatz zu ASP weitgehend Plattformunabhängig, während ASP eigentlich nur für Windows gemacht wurde und gerade erst eine UnixVersion raus ist...
Stimmt. Ein guter Vorteil.
Weiteres Plus von Perl: Es ist verbreitet und (was von vielen, die nur CGI sehen unterschätzt wird:) es hat sich für Administrationsskripten auf Unix/Linux ebenfalls gut durchgesetzt.
Stimmt.
Ähnliches gilt übrigens auch im Vergleich Perl vs. PHP.
Ich würde gar nicht so sagen, Perl gegen PHP oder sonstwas .....
Jeder der Konzepte hat stärken und Schwächen. Für den gegebenen Fall das Beste zu finden, darauf kommt es an. Perl hat natürlich den Vorteil, daß es unabhängig und mächtig ist und damit ASP und PHP ersetzen kann. Wer aber kein Problem damit hat was Neues zu lernen der ist zumindest bei einfachen Problemen mit ASP/PHP besser bedient, aufgrund der kürzeren Entwicklungszeit).
By the way mit JavaServerPages steht einem eine ähnliche Technologie zur Verfügung wie ASP/PHP nur hat man hier noch den Vorteil es mit Java zusammen einsetzen zu können. Die Kooperation zwischen ASP/PHP mit Perl klappt dagegen nicht ganz so gut. Und Java ist auch unabhängig. Man hat dann halt alles unter einem Dach. Eine Gesamtlösung und die Plattformunabhängig. Auch nicht schlecht.
Avber wie gesagt, kommt auch immer auf die Gegebenheiten und auf die Wünsche an, die man hat.Gruß
Michael-
Hallo Wolfgang und Michael,
danke für Eure Kommentare. Ich sehe es ähnlich. Aber nochmal zu Michael und der "Entwicklungsgeschindigkeit". Ich bin (rel.) fit in Perl, ASP ist nun nicht so mein Thema. Vor allem stört mich das, was du vielleicht als Vorteil siehst: Die Vermischung von Quellcode und Struktur (HMTL). Das ist, wie ich zur Zeit erfahren muß, u.U. reine Quälerei! XML, CSS sind z.B. genau gegenteilige Konzepte, die zwar noch nicht vollständig umgesetzt sind, aber in die richtige Richtung laufen.
Zur Zeit habe ich einen Kunden, der unbedingt ASP-Seiten haben will, in denen HTML, server(ASP)- und clientseitiges JavaScript ist. Das serverseitige ASP greift auf eine DLL zu, die auf die Datenbank zugreift...
Abgesehen davon, daß hier 1001 Techniken verwendet werden, ist der ganze Kram auch nicht mehr zu lesen!
In Perl würde ich das ruckzuck erledigt haben (schon wegen der hier-Anweisung, womit man einfach HTML-CODE im Klartext reinposten kann), aber die tausendfach ineinandergeschachtelten document.write bzw. response.write kann man einfach nicht mehr als "ordentliche/saubere" Programmierung bezeichnen. Das meinte ich mit Entwicklungsgeschwindigkeit!Reiner
-
Hallo Reiner,
.... Aber nochmal zu Michael und der "Entwicklungsgeschindigkeit". Ich bin (rel.) fit in Perl, ASP ist nun nicht so mein Thema. Vor allem stört mich das, was du vielleicht als Vorteil siehst: Die Vermischung von Quellcode und Struktur (HMTL). Das ist, wie ich zur Zeit erfahren muß, u.U. reine Quälerei!
Hab bewußt gesagt, kommt auf die Situation an. Und bei einfachen Problemen hat diese Mischung durchaus Sinn, weil halt zusammen ist, was zusammengehört. Mit Perl generiere ich ja letzlich ein HTML-Dokument. Warum also nicht ein fertiges HTML-Dokument (was sich dann auch prima mit Generatoren erstellen und designen läßt) und die benötigten Operationen einfügen? Ist also schon eine recht gute Sache.
Zur Zeit habe ich einen Kunden, der unbedingt ASP-Seiten haben will, in denen HTML, server(ASP)- und clientseitiges JavaScript ist. Das serverseitige ASP greift auf eine DLL zu, die auf die Datenbank zugreift...
Nunja ..... vielleicht weil es um Weiterentwicklung geht und er in seiner Abteilung/Firma ASP-Profis hat oder was weiß ich warum. Man sollte mal über die Gründe diskutieren und kann dann ja Alternativen darlegen, wenn es sinnvoll ist.
Abgesehen davon, daß hier 1001 Techniken verwendet werden, ist der ganze Kram auch nicht mehr zu lesen!
Ja, viele Techniken, daß nervt mich auch. Lieber ein Konzept, was durchgehend verwendbar ist. Das wäre am besten. Das mit dem Java geht ja schon in eine ganz gute Richtung.
Leider gibt es noch keine universelle Technologie die sich durchgesetzt hat. Wir müssen uns also weiter mit vielen Dingen rumplagen.Gruß
Michael
-
-
-
-
Ich diskutiere gerade mit ein paar Leuten eine Serverproblematik aus.
- Version 1
- NT-Server
- Microsoft IIS
- MSQL-Datenbank
- ASP-Seiten
- eigene DLL, die bestimmte Befehle an die Datenbank weiterleitet
- Version 2
- Linux (allg. Unix)- Server
- Informix-Datenbank
- Perl-Module (entsprechend der DLL von Version 1)
Um über die Geschwindigkeit der auf einem solchen Modell basierenden Anwendung diskutieren zu können, fehlen mehrere essentielle Informationen:
a) Von welcher Datenmenge reden wir? (Zehnerpotenz der Datensätze reicht.)
b) In welchem Anteil sind lesende bzw. schreibende Zugriffe erforderlich?
c) Sind die Zugriffe nachvollziehbar (d. h. viele gleichartige Zugriffe, also wenige verschiedene SQL-Anweisungen, die sich gut individuell tunen lassen) oder "streuen" sie (beliebige Auswahl einer großen, heterogenen Datenmenge?
Es gibt Leute, die meinen, weil ja die DLL im Speicher gehalten wird, die Perlprogrämmchen aber jedesmal starten müssen (ist das das wirklich so???), wäre die Geschwindigkeit bei Version 1 weitaus höher.
Wenn die Datenmenge groß genug ist, um den Einsatz einer Datenbank wirklich zu rechtfertigen, kann man m. E. *alle* anderen Faktoren bezüglich der Geschwindigkeit vernachlässigen.
Im Bereich der Datenbanken kann eine einzige "zweitbeste" Entscheidung mühelos Auswirkungen haben, die Faktor 10, 100 oder noch mehr an Performance ausmachen. So etwas schaffst Du weder mit einem schlechten Betriebssystem noch mit einer schlechten Hardware - höchstens mit sehr schlechten Algorithmen in der eigenen Anwendung (quadratisches Sortieren von 10^n Daten etc.)
Und damit meine ich nicht, daß die Entscheidung pauschal zwischen MSQL und Informix fällt, sondern daß sie davon abhängig ist, welche der beiden Datenbanken die konkret erforderlichen Maßnahmen für das interne Datenbank-Tuning bzw. die Konsistenz der Daten (Indexierung, Clusiering, Constraints, Trigger, ...) besser unterstützen.
Zudem SEHE ich einfach, daß Version 1 auch Geschwindigkeitsprobleme hat.
Ich halte es für irre schwierig, zwei solche Systeme in Sachen Performance pauschal zu vergleichen, selbst wenn es sich um identische Applikationen handeln sollte.
Vielleicht ist die eine der beiden Datenbanken einfach schlechter getuned als die andere, weil beim Entwurf der Dienstleistung die eine Datenbankversion besser verstanden und die Anwendung später "nur" portiert wurde?
Richtig gute DDL zu schreiben ist etwas, was man als normaler Entwickler trotzdem mühsam lernen muß, weil der Denkansatz ein so völlig anderer ist als in 3GL-Sprachen.Gibt es dazu Erfahrungen, Meinungen?
Wie gesagt: Die Relevanz der einzelnen Komponenten hängt davon ab, was für Daten Du verarbeiten willst. (Volumen und Konsistenzforderungen.)
Die Relevanz der Wartbarkeit (Entwicklungsgeschwindigkeit) hängt übrigens stark davon ab, wie genau man zum Zeitpunkt des Auftrags spezifizieren kann, was das Produkt später leisten soll.
Nur wenn man hier pfuscht (Auftraggeber wie Auftragnehmer), ist ein Werkzeug für schnelle Weiterentwicklung eine spürbare Erleichterung ... ;-)