PDA

View Full Version : AS/400->Microsoft SQL Server: JDBC getConnection langsam


Klaus Mödinger
26-07-17, 12:21
Hallo,

ich verbinde mich via JDBC mit einem SQL Server SQLEXPRESS 64Bit, Version 11.0.6248.0 auf Windows Server 2012 R2.

Clients sind diverse IBM i (AS/400) V7R2 mit Java 1.71. JDBC-Treiber ist sqljdbc41.jar von Microsoft.

Auf fast allen IBM i dauert DriverManager.getConnection ca. 15 Sekunden. :-(

Es gibt *eine* IBM i-Umgebung, auf der die Verbindungsaufnahme flott funktioniert.

Hier Ausschnitte aus zwei JDBC-Traces:

Langsame Performance:
21.07.2017 11:11:46 com.microsoft.sqlserver.jdbc.TDSChannel enableSSL
MAXIMAL: TDSChannel (ConnectionID:1) Creating SSL socket
21.07.2017 11:12:03 com.microsoft.sqlserver.jdbc.TDSChannel$ProxySocke t getInputStream

Normale Performance:
21.07.2017 11:14:11 com.microsoft.sqlserver.jdbc.TDSChannel enableSSL
MAXIMAL: TDSChannel (ConnectionID:1) Creating SSL socket
21.07.2017 11:14:12 com.microsoft.sqlserver.jdbc.TDSChannel$ProxySocke t getInputStream

Im schlechteren Fall dauert das Erzeugen eines SSL-Sockets offenbar über 15 Sekunden.

Woran könnte das liegen?

PS: Dieser Java-Vierzeiler erzeugt einen SSL-Socket in allen Umgebungen schnell:
SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
logLine("Creating ssl socket ...");
SSLSocket soc = (SSLSocket) factory.createSocket();
logLine("Ssl socket created!");

PS2: Abstellen von SSL im Connection String mit encrypt=false hilft nichts,
da die Verbindungsaufnahme trotzdem mit SSL läuft.

PS3: Das File java.security ist auf allen IBM i identisch.

PS4: Mit dem jtds-Treiber gibt es dasselbe Performance-Problem.
Zerberus77
26-07-17, 20:05
Hallo Klaus,

ich würde auf DNS oder lokale Host Tabelle tippen.

Wie sieht den ein TRCCNN für die schnelle und langsame Verbindung aus?

MFG Zerberus
Klaus Mödinger
27-07-17, 08:53
Hallo Zerberus,

TRCCNN habe ich noch nicht probiert, aber es gibt ein Wireshark-Protokoll für eine langsame Verbindung, Ausschnitt hier: http://www.comsid.de/wireshark.txt

Bemerkenswert ist die lange Pause zwischen Frame 30 und Frame 31. Der Client schickt Daten, wartet 16 Sekunden und schickt wieder Daten. Was macht der in den 16 Sekunden?

Sieht man sich den JDBC-Trace an, könnte man vermuten, er braucht die 16 Sekunden, um den SSL-Socket zu erzeugen, über den dann Frame 31 gesendet wird?

Viele Grüße,
Klaus
BenderD
27-07-17, 09:12
... ist der zweite connect im selben Job genauso langsam?
Klaus Mödinger
27-07-17, 09:25
Hallo,

ja, d.h. jein. ;-) Der erste Connect in einem frischen Job dauert ca. 30 Sekunden. Da sind dann die 15 Java-Gedenksekunden zum Starten der JVM dabei.

Alle weiteren Connects bei im Job geladener JVM dauern dann so 15 Sekunden.

Viele Grüße,
Klaus Mödinger
BenderD
27-07-17, 09:37
... hast Du die DNS config mal überprüft? CFGTCP dann Auswahl 10 und 12 (zweite Seite beachten) und die eingetragenen Adressen pingen.

D*B
Klaus Mödinger
27-07-17, 09:50
Hallo Dieter,

da war als zweiter DNS-Server in der Tat ein Quatsch aus der Vergangenheit drin. Den habe ich rausgeschmissen. Hilft aber leider auch nix.

Viele Grüße,
Klaus Mödinger
Klaus Mödinger
27-07-17, 15:34
Hallo,

Zerberus77' Nase lag goldrichtig. Es war in der Tat ein DNS-Problem.

Irgendwas ist an unserem Router doof. ;-) Und an einem DNS-Server an einer Kundenlokation.

Ich habe auf der IBM i als einzigen DNS-Server Googles 8.8.8.8 eingetragen - und siehe da: läuft alles flott. Mit wem Microsoft da sonst noch telefonieren möchte, bekäme man vermutlich mit TRCCNN raus.

Vielen Dank nochmals für eure Antworten!

Schönen Gruß,
Klaus