Liebe Netzwerkprofis,
hoffe auf eure Hilfe und euren Sachverstand.
Zunächst ich bin ein Neuling in C#.
Habe eine Anwendung programmiert und diese im Netzwerk verteilt.
Als Datenbank nutze ich eine Access-Datei (bitte keine Datenbank oder nicht Diskussion starten).
Mein Programm eine einfache Windows-Forms-Anwendung (keine Web-Anwendung).
Die Access-Datei befindet sich auf einem freigegebene Laufwerk im Intranet.
Bei mir am Standort läuft die Anwendung flüssig und schnell.
Da auch der Datei-Abruf sehr schnell von statten geht.
Nur bei einem anderen Standort (ca. 20 km entfernt / schlechte 25000er Leitung) über Intranet, läuft die Anwendung verzögert und sehr langsam (Die Datenbank-Abfrage dauert sehr lange).
Die Abfrage sieht etwa so aus:
// Eröffnen einer neuen DB Verbindung
OleDbConnection connectionDB = new OleDbConnection();
//Verbinden mit der Datenbank
connectionDB.ConnectionString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + DataDbFolder + ";Persist Security Info=False;";
connectionDB.Open();
//Abfrage einrichten
OleDbCommand command = new OleDbCommand();
command.Connection = connectionDB;
// Abfrage Text übergeben / abfragen
command.CommandText = Abfragewert;
OleDbDataReader reader = command.ExecuteReader();
Ich weiß mit Webtechnologien würde ich bessere und schnellere Ergebnisse erzielen.
Aber dann kann ich keine Windows-Forms-Anwendung nutzen.
Habt ihr eine Idee, diese Abfrage im Intranet mit schlechter Leitung zu beschleunigen?
Das betrifft übrigens nicht nur Datenbanken, sonder auch das öffnen einfacher Dateien im Netzwerk. Wenn man von dem Standort eine Word-Datei öffnet, dauert es sehr lange, bis die Word-Datei als Kopie geladen wurde.
Evtl. gibt es auch eine generelle Beschleunigung des Intranets mit schnelleren Routern, etc.?
Würde mich über jegliche Hilfe sehr freuen.
Lieben Gruß
ck
.NET kann nichts dafür, dass die Latenz der Leitung schlecht ist.
Das kann .NET hier auch nicht ändern.
Das einzige, was Du hier optimieren kannst, ist die Menge an Resultaten, sodass weniger Daten über die Leitung gehen muss.
Das ist aber auch das einzige.
Zum Rest (Technologisch) soll man sich ja nicht äußern laut Deiner Bitte...
PS: Es gibt "Router" mit WAN Compression (WAN acceleration appliances); aber das wird teuer.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Mit 20 Km kann ich mir ein persönliches Intranet nur schwer vorstellen, kann auch meine begrenzte Erfahrung damit sein.
Da wäre die Leitungen von A bis nach B interessant. Ist diese durchgehend schwach oder nur einzelne Längen davon?
Wie ist diese verlegte Leitung grundsätzlich ausgelegt?
Laufen noch andere Leitungen (egal welche) daneben mit?
Zweigen diese öfters noch woanders ab?
Meine Fragen haben eigentlich nur was mit der Hardware zu tun 😁
Ich habe den Titel mal angepasst, so dass Suchende auch etwas damit anfangen können. EDIT: Ich sollte beim Wort "Shift" im Titel das "f" nicht vergessen... 😄
Sofern programmtechnisch nichts verändert werden soll/darf, bietet sich vielleicht ein Remotedesktop-Server an:
RDP erzeugt viel weniger Traffic als Abfragen auf eine große Access-Datenbank.
Ich hab' mal einen Fall erlebt, da lief eine Access-Anwendung auch im lokalen Netzwerk sehr langsam. Die Access-Datenbank war 1,6 GB groß. Letztendlich hat man sich damit beholfen, die Netzwerkverbindung von 100 MBit auf 1 Gigabit umzustellen 🤔
Ich weiß mit Webtechnologien würde ich bessere und schnellere Ergebnisse erzielen.
Aber dann kann ich keine Windows-Forms-Anwendung nutzen.
Ich glaube du solltest nochmal ganz genau schauen was du hier falsch verstanden hast.
Natürlich könntest du einen WebService erstellen und aus einer WindowsForms Anwendung aufrufen.
Datenbankabfragen gibt es beim OldDbZugriff auf eine AccessDatei nicht.
Die Engine liest alles aus der Datei, das ist der Grund warum die so langsam ist.
Und warum keine Diskussion zu der schlechten Wahl?
Dir wird bei Access und Netzwerk über kurz oder lang ( eher kurz ) die Datenbank korrupt werden und dann ist das Geschrei groß.
Klingt nach einer Kopplung eurer Standorte über VPN.
Da der Netzverkehr dann auch vom Router verschlüsselt wird, sinkt auch der Durchsatz.
Je nachdem wieviele Standorte dann gekoppelt sind, sinkt auch der Durchsatz der Verbindung zu eurem Standort.
Dann wäre nur wichtig wie der Standort an dem die Freigabe herkommt angebunden ist.
I.d.R. sind die meisten Handelsüblichen Router bei VPN auf rund 20 MBit/s limitiert wegen der geringen CPU Leistung.
Mit entsprechender Hardware ginge da auch mehr, kostet dann aber einige mehr als man im einfachen Handel bekommt.
Ansonsten klingt, wie schon von allen gesagt, das generelle Konzept problematisch.
Hier wäre auch zu überlegen, ob deine Anwendung nicht auf eine lokale Kopie der Daten vorhalten kann.
Dafür würde sich dann auch eine Embedded DB wie Sqlite anbieten.
Wäre zwar zusätzlicher Aufwand, würde aber den Traffic nur zum einmaligen Abholen der Daten verringern.
Aktuell müsste jede Anwendung die Daten immer wieder holen, was bei knapper Bandbreite vermieden werden muss oder eben durch lokale Caches, lokale Datenbank, Objekt Cachen etc., vermieden werden muss.
Eine sinnvollere Umsetzung wäre ein zentraler Webservice, der die Daten aus einer richtigen DB wie MS Sql Server oder Postgresql o.ä. lädt und ausliefert.
Dann kann deine WinForms Anwendung via WebAPI die Daten abholen.
Dann musst du nicht auf deine WinForms Anwendung verzichten sondern nur dein aktuelles Backend austauschen bzw. durch einen richtigen Webservice implementieren.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Vielleicht würde es helfen, eine Serveranwendung zu entwickeln, die irgendwo am Standort wo die Access-Datei liegt, läuft.
Die Clients verbinden sich dann zu dieser, und nur die Serveranwendung macht Zugriffe auf die Access-Datei und gibt die Ergebnisse an die Clients zurück.
Dadurch würdest Du den Remote-Dateizugriff sparen und hättest dann nur noch den normalen Kommunikations-Traffic zwischen Client und Serveranwendung, der wohl relativ flüssig laufen dürfte, so lange Du keine riesigen Datenmengen aus der Access-Datei übertragen musst.
Letztlich hängt die Verzögerung aber immer in erster Linie davon ab, wie groß die Datenmenge ist, da hilft dann nur eine bessere Leitung oder eine Verkleinerung der Datenmenge. Um Letzteres zu erreichen, könnte Deine Serveranwendung die Daten nach dem Auslesen aus Access ggf. noch in geeigneter Form komprimieren, bevor sie an den RemoteClient weitergeleitet werden.
Hallo an alle,
möchte euch allen für eure Beiträge danken.
Hatte gehofft mir etwas Arbeit zu sparen, werde aber vermutlich nicht drum herumkommen.
Den Vorschlag von Abt werde ich mit unserem System-Admin mal prüfen (WAN Compression).
Aber nach erstem Telefongespräch wird das nicht viel bringen und daher müssen wir vermutlich den Weg über Änderung der Programme gehen.
Blöd für mich ist nur, dass ich zwei Programme ändern muss. Eine Windows-Dienst-Anwendung und eben die GUI-Anwendungen der User (win Form).
Heißt SQL aufsetzen, Windows-Dienst-Anwendung und GUI-Anwendungen anpassen.
Am besten gleich noch in Verbindung mit WebAPI wie von T-Virus vorgeschlagen.
Alternativ werde ich den Vorschlag von Mallett umsetzen. Wenn ich mich sowieso mit WebAPI beschäftigen muss, könnte ich evtl. wirklich nur einen Server-Dienst zwischen schalten.
Euch allen nochmals vielen Dank für die zahlreichen Rückmeldungen und hilfreichen Vorschläge.
Gruß
ck
Hier wäre auch zu überlegen, ob deine Anwendung nicht auf eine lokale Kopie der Daten vorhalten kann.
Das gilt es immer zu vermeiden. Nichts ist komplexer als Caching.
Solange nicht alle technischen Möglichkeiten ausgeschöpft sind, sollte man die Finger von Caching lassen.
Wäre zwar zusätzlicher Aufwand, würde aber den Traffic nur zum einmaligen Abholen der Daten verringern.
Nicht unbedingt. Wie so oft: kommt drauf an.
Eine sinnvollere Umsetzung wäre ein zentraler Webservice, der die Daten aus einer richtigen DB wie MS Sql Server oder Postgresql o.ä. lädt und ausliefert.
Dann kann deine WinForms Anwendung via WebAPI die Daten abholen.
👍
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code