none
RDS vs. Netzlaufwerk Speed Issues RRS feed

  • Frage

  • Hallo zusammen,

    ich habe auf einem Win08R2 Server ein Programm zu laufen, sehr viele DB-Anfragen, eine Any???SQL Datenbank... dahinter.

    Wenn ich per RD auf den Server gehe, läuft der ganze Spaß "einigermaßen" "zufriedenstellend"

    Ziehe ich mir den (mitangebotenen Client) auf den lokalen Rechner ist die Performance scheiße (50Mbit-Leitung: UpAndDown sind absolut gut). Ziehe ich mir per DragDrop! eine 3-5GB! Datei auf meinen Desktop -als Speedtest-, läuft alles wunderbar.

    Es hängt also nicht am alten Access-Problem: "Die Daten werden erstmal zum Client geschaufelt" Selbst die Demo DB bremst wie Sau.

    Frage:
    Kann ich an den Verbindungsgeschwindigkeiten zwischen Netzlaufwerk vs. RDP irgendwas drehen?

    EDIT: Zum Beispiel
    \\192.168.1.1\myshare\  vs.    \\COMPUTER\myshare vs.    \\192.168.1.1\'C:\ProgramFiles\bla..\bla\'
    (vor vielen Jahren hieß es mal das vor allem die zweite jedesmal aufgelöst werden müsste - Ich komm von Access - und das würde sehr radikal an der Performance nagen) Bei letzerer kenn ich die richtige Nomenklatur gerade nicht

    Alternativ würde ich ggf. die "guten" ODBC-Verbindungseigenschaften kopieren, und nur die Ziel IP ändern

    Danke im Voraus

    Raimo


    Freitag, 15. Juli 2016 20:43

Antworten

  • Ach, Lexware... die nutzen also immer noch Sybase. Dann kannst Du erfahrungsgemäß serverseitig gar nichts machen, ohne den Support zu verlieren, und mit jedem Update wird es eh zurückgesetzt.

    Ich hatte das früher recht oft, als ich noch für typische LExware-Kunden gearbeitet habe ;-) Allerdings waren meine Kunden auch oft Terminalserver-Kunden, und auf dem Wege konnte mand as dann doch in ausreichender Qzualität bereit stellen.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert RaimoBecker Sonntag, 17. Juli 2016 16:15
    Sonntag, 17. Juli 2016 16:06

Alle Antworten

  • Frage:
    Kann ich an den Verbindungsgeschwindigkeiten zwischen Netzlaufwerk vs. RDP irgendwas drehen?

    Moin,

    Gegenfrage: Kannst Du das Ganze per Netzlaufwerk, aber über ein "echtes" LAN testen?

    Ansonsten: Welche Latenz und welche MTU hat Dein WAN? Die Bandbreite ist bei so etwas eher nicht entscheidend.

    Und: Welcher ODBC-Treiber genau kommt da zum Einsatz?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 15. Juli 2016 20:52
  • Hallo Evgenij,

    Ja. Ich habe das Programm hier lokal auf einem 2012Server laufen.

    Ein PC(8GB) ein LT(8GB) per Kabel dran. Beide haben zusätzlich eine !!komplett nackte!! VM (je 3GB abzüglich) laufen.

    Vier Programme laufen ~naja .NET braucht viele Ressourcen *4~ relativ in Ordnung.
    Keine High Performance, aber man könnte mit leben.

    Ich habe schon die Firewalls abgeschaltet: Fritzbox-ExposedHost ; Rechner FW abgeschaltet.

    Nach innen gehts einigermaßen, außen ist grrrrr....

    Danke Raimo

    -----

    Sorry der Treiber ist ein SQL ANYwhere 16

    Seine Config vom Programm ist der Host und die DB
    der Rest ist Blank.
    Sorry, wenn ich sowas sehe. Ich muss da wohl noch EINIGE Parameter eingeben

    Freitag, 15. Juli 2016 21:04
  • Moin,

    verrätst Du noch die Antworten auf die restlichen drei Fragen (MTU, Latenz und ODBC-Treiber)?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 15. Juli 2016 21:08
  • Mahlzeit.

    Ich treibe mich sonst in der Programmierer-Ecke herum.

    Sorry:

    MTU: 1500 für zwei Adapter + eine

    ODBC: hast DU! das ist wieder halb meien Terrain

    Latenz? ggü meinem Remote! als Ping???

    Antwort von x.x.x.x  32;44;119

    Bin Ich falsch

    Freitag, 15. Juli 2016 21:31
  • Hmm. 30 - 100 ms Latenz kann für einen DB Zugriff suboptimal sein, je nachdem wie er gelöst ist. (ich kenne ein Software-Produkt, da wird zu jedem Mausklick in der GUI aus der ORACLE-Datenbank ein VBScript nachgeladen. Steht die DB weit weg, ist die GUI entsprechend träge).

    MTU=1500 ist eingestellt, und was geht tatsächlich durch? Man muss 28 Byte Overhead abziehen, d.h. in Deinem Fall müsste

    ping <Gateway> -f -l 1472 durchgehen, sonst musst Du die MTU selbst im LAN verringern.

    Noch interessanter ist aber, welcher Wert noch von Quelle zum Ziel durchgeht. Zu dem solltest Du 28 addieren und das sowohl auf dem Server als auch auf dem Client als MTU einstellen. Durch diese Maßnahme hast Du zumindest keine Fragmentierung mehr.

    Die Doku zum SQLAnywhere-ODBC-Treiber bin ich kurz überflogen und erst einmal nichts entdeckt, was in Richtung Netzwerk-Optimierung ginge. Vielleicht kann man am Server selbst auch Startparameter einstellen, z.B. http://dcx.sap.com/index.html#sa160/en/dbadmin/p-database-dbengine.html -- der Wert müsste natürlich knapp unterhalb der MTU liegen. 


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Freitag, 15. Juli 2016 21:58
  • Hallo EvgeniJ,

    danke für die Infos.

    MTU kannte ich nicht, diese sind aber scheinbar in Ordnung.
    Am ODBC-Driver kann ich selber herumwerkeln, der ist nicht das Problem. Ich schieße von hier diverse SELECTS FROM WHERE ab, und die sind alle ziemlich fix.
    Auch läuft auf dem Server eine kleine MS-SQL DB, die läuft auch schnell. Mit LAN-Kabel an der Fritze und mit Luftkabel.

    Deine Idee mit der GUI scheint mir plausibel. Es ist eine Lexware-Anwendung, die auch lokal nicht gerade zum performantesten zählt.

    Danke erstmal
    Raimo

    Sonntag, 17. Juli 2016 15:59
  • Ach, Lexware... die nutzen also immer noch Sybase. Dann kannst Du erfahrungsgemäß serverseitig gar nichts machen, ohne den Support zu verlieren, und mit jedem Update wird es eh zurückgesetzt.

    Ich hatte das früher recht oft, als ich noch für typische LExware-Kunden gearbeitet habe ;-) Allerdings waren meine Kunden auch oft Terminalserver-Kunden, und auf dem Wege konnte mand as dann doch in ausreichender Qzualität bereit stellen.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert RaimoBecker Sonntag, 17. Juli 2016 16:15
    Sonntag, 17. Juli 2016 16:06
  • Ja. diese Software (mit einem lauten und langem ach... und hmmmf... ) hinterher

    OK, ich bin wohl hier nicht allein.

    Ich schließe das Thema und danke Dir

    Gruß Raimo

    -Terminalserver ist bei denen immer noch ganz hoch im Kurs-

    Sonntag, 17. Juli 2016 16:15