Hallo@all... Ich habe da mal ne Fräge an euch... Zuerst ein bisschen Hintergrund: Ich entwickle derweil in VisualBasic.net eine Standard-WindowsApplication welche auf einen entfernten oder auch lokal betriebenen MySql5 Server zugreift und nachdem ich Commandos hingeschickt habe empfange ich auch Daten, oder es werden Daten gelöscht, und, und, und... Das funktioniert auch alles hervorragend. Nur... Lasse ich die Connection an und für sich zum MySql-Server während der Programmbenutzung offen, und schließe sie erst bei Programmende, oder öffne und schließe ich sie nach jedem Vorgang (Befehl und Datenempfang ggf. LastInsertID)??? Ich habe dazu im Netz eigentlich immer nur gelesen, das man die Verbindung so schnell wie möglich wieder schließen sollte, aber warum? Wenn sich der Datenbank-Server im Inet befindet kann es je nach Verbindung ja auch mal 1-2 Sekunden dauern, bis er alleine die Verbindung hergestellt hat. Das würde mich als Benutzer des Programms empflindlich stören. Weiss da jemand ein wieso oder warum? Vielen herzlichen Dank schonmal im Voraus, GGaasstt
> ... Verbindung so schnell wie möglich wieder schließen ...
Ist nur in Verbindung mit Webapplikationen sinnvoll, wo mehr
Web-Zugriffe gleichzeitig erfolgen als der Mysql-Server an parallelen
Threads/Connections zulässt.
=> Wenn deine Anwendung nicht für massiven Multiuser-Einsatz gedacht
ist, Verbindung einfach offenlassen.
So ungefähr dachte ich mir das nämlich auch. Also, wenn z.B. ein gut besuchter WebShop am MySQL-Server hängt, Verbindung schnellstmöglich trennen. Isses "nur ein" Daten-Server für Kassensysteme, Vereinsverwaltungen und sonstiger kleinkram kann ich die offenlassen... Vielen Dank nochmal. Wollte mich nur vergewissert wissen, GGaasstt
GGaasstt schrieb: > Also, wenn z.B. ein gut besuchter WebShop am MySQL-Server hängt, > Verbindung schnellstmöglich trennen. Auch nicht unbedingt, da können auch Persistent Connections Sinn machen. Hängt davon ab, wieviel Zugriffe passieren, und wieviele davon wirklich MySQL benötigen usw...
GGaasstt schrieb: > Lasse ich die Connection an und für sich zum MySql-Server während der > Programmbenutzung offen, und schließe sie erst bei Programmende, oder > öffne und schließe ich sie nach jedem Vorgang (Befehl und Datenempfang > ggf. LastInsertID)??? Der Aufbau einer Verbindung zu einem MySQL-Server ist bei weitem nicht so unaufwändig wie man das gerne glauben möchte. Relativ zu anderen Datenbanken ist MySQL da in der Tat recht flott, aber in absoluten Zahlen ist der Aufbau einer SQL-Connection immernoch eine ressourcenintensive Operation. Man kann diesem Problem etwas entgegenwirken, in dem man den MySQL-Server eine Anzahl "vorbereiteter" Threads erzeugen lässt ("MySQL Thread Cache"), die bei clientseitigen Verbindungswünschen sofort zur Stelle sind. Siehe: http://dev.mysql.com/doc/refman/5.1/en/connection-threads.html Möglicherweise kannst Du auch clientseitig die Verbindung zum Server nach einer gewissen Leerlaufzeit einfach zumachen. Wenn die Applikation die Datenbank also nicht ständig mit Abfragen befeuert räumt man so zumindest teilweise die ganzen serverseitigen Thread-Leichen auf, die außer Speicherverbrauch und Zeitverbrauch im Scheduler zu nichts nütze sind. Ohne Deine Applikation und ihr Verhalten näher zu kennen ist es jedoch schwierig, Dir gute Ratschläge zu geben. Im Zweifelsfall wäre sowas über einen ordentlichen Performance- oder Lasttest zu entscheiden. > Ich habe dazu im Netz eigentlich immer nur gelesen, das man die > Verbindung so schnell wie möglich wieder schließen sollte, aber warum? Hier - http://www.mysqlperformanceblog.com/2006/11/12/are-php-persistent-connections-evil/ - findest Du ein paar Gründe, warum man vor allem Entwicklern von (PHP-basierten) Webapplikationen gerne zu sowas rät. Das andere Extrem ist nämlich: Manche Entwickler kommen tatsächlich auf die Idee, Datenbankverbindungen in Sessions zu speichern, weil sie glauben, sie würden Transaktionen benötigen, die sich über mehrere HTTP-Requests erstrecken. Ich persönlich halte das Dogma, Datenbankverbindungen müssten so schnell wie möglich geschlossen werden, für Unfug. Bei Web-Appikationen beispielsweise, bei denen eine Hand voll Applikationsserver mit einer Datenbank interagieren, sind ordentlich dimensionierte Connection Pools mit relativ langlebigen Verbindungen zur Datenbank unabdingbar. In Deinem Fall kann das anders sein, da Du vermutlich deutlich mehr als nur eine Handvoll Applikationsinstanzen am laufen haben wirst. Überhaupt halte ich Konstrukte, bei denen Clients direkt auf die Datenbank zugreifen, für äußerst zweifelhaft. Aus meiner Sicht hat eine Lösung mit einem zentralen Applikationsserver nur Vorteile. Sag doch mal - was für Vorteile hat Dein Konstrukt gegenüber einer Lösung, die z.B. auf einem zentzralen Webservice aufsetzt (was Clientseitig implementierte Logik ja in keinster weise ausschließt!)? > Wenn sich der Datenbank-Server im Inet befindet kann es je nach > Verbindung ja auch mal 1-2 Sekunden dauern, bis er alleine die > Verbindung hergestellt hat. Das würde mich als Benutzer des Programms > empflindlich stören. Mich auch - und wenn der Aufbau einer Verbindung 1-2 Sekunden dauert dann möchte ich ja garnicht wissen, welche hohen Latenzzeiten beim Ausführen von Datenbankabfragen anfallen :-/ Stephan
Stephan M. schrieb: > Überhaupt halte ich Konstrukte, bei denen Clients direkt auf die > Datenbank zugreifen, für äußerst zweifelhaft. Aus meiner Sicht hat eine > Lösung mit einem zentralen Applikationsserver nur Vorteile. Die Webanwendung kann man doch als Applikationsserver verstehen? Vielleicht bei PHP noch nicht aber spätestens bei einer ASP/JSP sind das richtige anwendungen die nur im Kontext eines Webserver laufen. Warum sollte man dann noch einen Applikationsserver zwischenschalten?
Peter schrieb: > Die Webanwendung kann man doch als Applikationsserver verstehen? Jein. Eine Webanwendung ist i.A. eine Kombination aus einem Applikationsserver mit serverseitiger Logik und Clients (Browser) mit clientseitiger Logik (JavaScript). > Vielleicht bei PHP noch nicht aber spätestens bei einer ASP/JSP sind das > richtige anwendungen die nur im Kontext eines Webserver laufen. Warum > sollte man dann noch einen Applikationsserver zwischenschalten? Soll und muss man nicht. Der Fragesteller hat eine Applikation, die auf den Client-Rechnern läuft (er schrieb: "Ich entwickle derweil in VisualBasic.net eine Standard-WindowsApplication welche auf einen entfernten oder auch lokal betriebenen MySql5 Server zugreift"). Was er also macht, ist: Clientprogramm (auf Clientrechner) -> <WAN> -> Datenbankserver. Was ich für eine sinnvolle Lösung halte, ist: Clientprogramm (auf Clientrechner) -> <WAN> -> Applikationsserver -> Datenbank Stephan
@Stephan M. stimm in ging ja um eine richtige Anwendung. Aber da kann man auch ein teil der Logig in die DB verlagern. Wenn man z.b. nicht direkt auf die Tabellen zugreift sonder alles über Datenbank-Prozedure abwickelt. Die meiste Programm (und zwar nicht nur kleine Tools) greifen dirket ohne ApplicationServer auf die Datenbank zu. (Navision, Datev usw )
Peter schrieb: > Die meiste Programm (und zwar nicht nur kleine Tools) greifen dirket > ohne ApplicationServer auf die Datenbank zu. > (Navision, Datev usw ) Klar, kann man alles machen und funktionieren tuts ja meistens auch ohne Probleme. Ich persönlich halte halt nichts, wirklich garnichts von solchen "Lösungen". Der Fragesteller hat ja auch geschrieben: > Wenn sich der Datenbank-Server im Inet befindet Spätestens da fängts bei direktem Datenbankzugriff an, interessant zu werden. Auch wenn Über die Anwenderzielgruppe nichts bekannt ist möchte ich doch mal mutmassen, dass irgendwann einer daherkommt, der hinter einer Firewall sitzt. Eine Three-Tier-Lösung mit AS und Kommunikation auf HTTP-Basis hat (nicht nur) an dieser Stelle entscheidende Vorteile, ist aber andererseits i.A. auch nicht so schnell entwickelt. Stephan
Stephan M. schrieb: > Klar, kann man alles machen und funktionieren tuts ja meistens auch ohne > Probleme. Ich persönlich halte halt nichts, wirklich garnichts von > solchen "Lösungen". wenn man immer sehr viele Daten verarbeiten muss ist das aber wesentlich effizenter. Es macht kein Sinn von der Datenbank erst ein paar tausend datensätze abzurufen sie im Server miteinander zu verrechnen und dann daraus ein paar zeilen ergebniss zu ermitteln. Dann sollte man das ganze schon in der Datenbank machen. Aber meist geht es mit "normalen" SQL Abfragen aber nicht. Da macht es sich sehr gut mit Gespeicherten Prozeduren und temp Tabelle zu arbeiten. Und damit ist ein Teil der Logik schon on der DB.
Peter schrieb: > wenn man immer sehr viele Daten verarbeiten muss ist das aber wesentlich > effizenter. Es macht kein Sinn von der Datenbank erst ein paar tausend > datensätze abzurufen sie im Server miteinander zu verrechnen und dann > daraus ein paar zeilen ergebniss zu ermitteln. Das ist ja auch nicht der Sinn eines AS. > Aber meist geht es mit "normalen" SQL > Abfragen aber nicht. Da macht es sich sehr gut mit Gespeicherten > Prozeduren und temp Tabelle zu arbeiten. Und damit ist ein Teil der > Logik schon on der DB. Schon klar - eine moderne DB kann deutlich mehr als nur Antworten auf Fragen wie "Welcher Premium-Kunde hat heute Geburtstag?" liefern. AS und datenbankseitige Logik (Stored Procedures) ergänzen sich ja oft. Egal ob man jetzt einen Client mit direktem Datenbankzugriff hat oder eine Dreischichtenlösung mit Client, AS und DB - irgendwo muss die Programmlogik ja nun hin. Meine Argumente für den Einsatz eines AS sind die zusätzlichen Freiheitsgrade, die man mit einem solchen Aufbau erkauft, denn man kann z.B. zwischen zentraler und dezentraler Logik unterscheiden (und die zentrale Logik dann weiter in AS-seitige und DB-seitige Logik aufteilen). Andererseits gibts ja für alles einen Markt, und ich will nicht abstreiten, dass ein Client mit direktem Datenbankzugriff durchaus eine erfolgreiche und auch effizient zu entwickelnde Lösung darstellen kann. Nur halte ich persönlich wenig von solchen Lösungen. Liebe Grüße, Stephan
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.