Datenbankverbindung und Packetsize
-
Hi,
ich habe 2 Szenarien, einmal einen Windowsclient, welcher sich auf eine Solarismaschin(DB) verbindet, und das das Programm direkt auf dieser Maschine läuft. Die Datenbank ist eine Sybase ASE 12.5
Ich habe jetzt entdeckt, das ich die Packetsize für die Verbindung festlegen kann, erste Tests haben auch gezeigt, das evtl. wirklich da etwas feintuning sinnvollsein könnte.
Jetzt habe ich von dem Thema aber relativ wenig Ahnung, daher würde mich interessieren welche Erfahrungen hier andere gemacht haben.
Bisher hatte ich das beste Ergebnis mit einer Packetsize von 4096.
512 ist Standard, und getestet habe ich 1024, 2048, 4096 und 8192.
Größere Werte ergeben für mich keinen Sinn mehr. Habe wohl bisher nur jeweils einen Import damit gemacht, gerade läuft die 2. Testrunde.
-
Du hast ja noch nicht einmal geschrieben was Du verwendest: Datenbanktechnologie / Framework / Clienttype, wie soll dir da jemand raten können? Außerdem weiß niemand was du optimieren willst.
-
witte schrieb:
Du hast ja noch nicht einmal geschrieben was Du verwendest: Datenbanktechnologie / Framework / Clienttype, wie soll dir da jemand raten können? Außerdem weiß niemand was du optimieren willst.
Was spielt das für die Packetsize für eine Rolle.
Mir gehts um Performance, das die Applikation beim Import evtl. schneller wird, wenn sie da schneller mehr über die Pakete an den Server geht.Sybase ASE 12.5, OpenClient als Verbindungslib, wo ich auch mit ct_con_props die Packetsize setze.
Allerdings sind die Ergebnisse sehr unterschiedlich, habe jetzt mit 4096 den besten und schlechtesten Test, wohl auf Solaris selber.Mich interessiert auch generell, ob schon andere mit einem solchen Parameter Performance von DB Anwendungen steigern konnten. Also ob die Netzwerkschnittstelle zum Tunen geeignet ist.
-
Solarisguy schrieb:
Was spielt das für die Packetsize für eine Rolle.
Mehr als du glaubst. Ich z.B. weiß nicht ob du die Paketgröße im TCP/IP-Stack änderst, in der Sybase-Client-Bibliothek (wenn sie sowas unterstützt) oder im Framework, wenn es dort eine abstrahierende DB-Verbindungsschicht gibt. Schließlich gibt es mehr als nur ein Protokoll und mehr als nur eine Ebene.
Beim Tunen ist es eigentlich üblich ein Problem zu definieren ("Beim mehr als 50 simultanen Verbindungen werden die Reaktionen des Servers zu langsam"), dann ein Ziel zu formulieren ("Bei 50 simultanen Verbindungen soll die Antwortzeit maximal 5 Sekunden bei einfachen Anfragen dauern") und abschließend zu versuchen dieses Ziel zu erreichen. Jetzt einfach so "rumzupoken" wird wohl eher wenig bringen, zumal du ja noch nicht einmal gleiche Testbedingungen hast oder es trivial ist.Solarisguy schrieb:
habe jetzt mit 4096 den besten und schlechtesten Test
-
witte schrieb:
Solarisguy schrieb:
Was spielt das für die Packetsize für eine Rolle.
Mehr als du glaubst. Ich z.B. weiß nicht ob du die Paketgröße im TCP/IP-Stack änderst, in der Sybase-Client-Bibliothek (wenn sie sowas unterstützt) oder im Framework, wenn es dort eine abstrahierende DB-Verbindungsschicht gibt. Schließlich gibt es mehr als nur ein Protokoll und mehr als nur eine Ebene.
Beim Tunen ist es eigentlich üblich ein Problem zu definieren ("Beim mehr als 50 simultanen Verbindungen werden die Reaktionen des Servers zu langsam"), dann ein Ziel zu formulieren ("Bei 50 simultanen Verbindungen soll die Antwortzeit maximal 5 Sekunden bei einfachen Anfragen dauern") und abschließend zu versuchen dieses Ziel zu erreichen. Jetzt einfach so "rumzupoken" wird wohl eher wenig bringen, zumal du ja noch nicht einmal gleiche Testbedingungen hast oder es trivial ist.Solarisguy schrieb:
habe jetzt mit 4096 den besten und schlechtesten Test
Also laut Sybase Doku (nicht wirklich ausführlich, daher kann ich dir das auch nicht so genau sagen), sind das TDS Packete, welche dann in TCP Ethernetframes gepackt werden, wenn ich es richtig verstanden habe.
Mein Ziel ist halt, das der Import schneller läuft, sprich weniger Zeit benötigt.
Leider haben wir hier keine genau definierte Testumgebung, so das ich leider etwas rumstochern muss, viel try n error.Mich interessiert hier aber nicht nur der konkrete Fall, sondern ob es Erfahrungen mit solchen Einstellungen bei Datenbankanwendungen gibt.