none
[Solved] JDBC getConnection langsam RRS feed

  • Frage

  • 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) 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$ProxySocket getInputStream

    Normale 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$ProxySocket 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.


    Mittwoch, 26. Juli 2017 11:11

Antworten

  • Hallo,

    Es war 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

    Donnerstag, 27. Juli 2017 14:38

Alle Antworten

  • Hallo Klaus,

    keine Ahnung, ob es hilft, aber verbindest Du Dich über den Servernamen oder die IP?

    Macht das einen Unterschied?


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Mittwoch, 26. Juli 2017 13:02
    Beantworter
  • Hallo Christoph,

    planmäßig verbinde ich über den Namen. Es macht aber keinen Unterschied, ob ich Name oder IP-Adresse verwende.

    Gruß,

    Klaus

    Mittwoch, 26. Juli 2017 14:14
  • Hallo Klaus,

    kannst Du mal probieren, den SQL Server über IP und Port anzusprechen? Ich kenne den ConnectionString für JDBC nicht, normalerweise gibt man das bei Verbindungen zum SQL Server in der Form:

    <IpAdresse>,<Port>

    also bspw.:

    10.1.1.1,1433

    an. Grund für diesen Test ist, dass in diesem Fall das TCP/IP Protokoll forciert wird. Evtl. probiert es der JDBC Treiber zuerst auf anderen Protokollen wie Named Pipes, ...

    (Auf dem SQL Server muss im Konfigurations-Manager das TCP/IP Protokoll natürlich auch aktiviert werden, falls das noch nicht gemacht wurde)

     


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community


    Mittwoch, 26. Juli 2017 16:07
    Moderator
  • Hallo Stefan,

    vielen Dank für Deine Antwort.

    Die Portangabe hat in der Verbindungszeichenfolge gefehlt, sie zu machen, brachte jedoch keine Verbesserung.

    Log (selbstgeschnitzt) für eine langsame Verbindung (Passwort ausgeblendet, SQL-Statement gekürzt):

    2017-07-26 22:55:46: SqlSrvCmd started...
    2017-07-26 22:55:46: Java version: 1.7.0
    2017-07-26 22:55:46: ConnectionString: jdbc:sqlserver://172.20.1.80:1433;user=sa;password=********;
    2017-07-26 22:55:46: Statement: insert into ... etc. etc. 
    2017-07-26 22:55:46: JDBC Driver loaded
    2017-07-26 22:56:03: Connection established
    2017-07-26 22:56:03: Statement created
    2017-07-26 22:56:03: Statement executed successfully!

    Sobald die Verbindung steht, geht alles blitzschnell.

    Viele Grüße,

    Klaus

    Mittwoch, 26. Juli 2017 21:08
  • Hallo Klaus,

    mit Java hab ich nix am Hut, daher weiß ich nicht, ob Du die neueren JDBC Treiber von Microsoft einsetzen könntest. Falls ja, wäre das sicher mal der erste Schritt, den man gehen sollte.

      https://docs.microsoft.com/en-us/sql/connect/jdbc/using-the-jdbc-driver

    Im ersten Posting hattest Du geschrieben, dass die Clients Java 1.7.1 einsetzen. In deinem Log steht 1.7.0. Ein Client geht ja anscheinend schnell. Ist bei dem zufällig die neuere Java Version im Einsatz?


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 26. Juli 2017 22:57
    Moderator
  • Hallo Stefan,

    an der Java-Version liegt es nicht. Ich habe dasselbe Phänomen auch mit älteren IBM i-Clients, die mit Uralt-Java 1.5 und einem Uralt-sqljdbc.jar-Treiber laufen.

    Einen neueren Treiber kann ich nicht verwenden. Die Client-Maschine, auf der das flott laufen soll ist eine IBM i V7R2M0, da ist Java 1.7(1) die höchstmögliche Java-Version, die ist 1:1 mit dem Treiber sqljdbc41.jar gekoppelt.

    Viele Grüße,

    Klaus

    Donnerstag, 27. Juli 2017 08:13
  • Hallo,

    Es war 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

    Donnerstag, 27. Juli 2017 14:38