Java Socket langsam unter Linux

[Guest]

Ich habe einen kleinen Socketserver in Java geschrieben, der für andere Anwendungen Übersetzungen bereitstellt. Dabei bin ich auf ein seltsames Phänomen gestoßen. Wenn das Programm unter Linux läuft braucht es wesentlich länger um Übersetzungen zurückzuliefern als unter Windows. Es ist ungefähr um den Faktor 3,7 langsamer. Während andere Java Anwendungen unter Windows und Linux annähernd gleich schnell sind. Die Javaversion tut nichts zur Sache, ich habe beides getestet J5 und J6 (sun). Auch die Hardware spielt keine Rolle, ich habe auf verschiedenen Rechnern getestet. Der Verbindungsaufbau Geschieht unter beiden Systemen gleich schnell und die Übertragungsgeschwindigkeit spielt auch keine Rolle. Die Getesteten Betriebsysteme sind Windows 2000 auf der einen und SuSE Linux 10.1 auf der anderen Seite.
Ich währe sehr dankbar wenn mir jemand weiter helfen, oder mir zumindest einen Tipp geben könnte wo ich noch suchen kann.

 

[Gast]

Vielleicht macht irgendeine Bibliothek einen DNS Reverse Lookup?

 

[schebl]

Das glaube ich nicht, die Zeit für den Verbindungsaufbau habe ich getrennt festgestellt, und die ist unter beiden Systemen gleich, sollte der also während der Kommunikation noch weitere Lookups machen, dürfte das trotzdem keinen Geschwindigkeitsunterschied ausmachen.

 

[Guest]

trag die clients mit ihren IPs in der /etc/hosts ein. hatte das auch mal und konnte es damals nur so lösen. ist aber sicherlich nur als workaraound zu werten.

 

[schebl]

derzeit ist der einzige client eine Webanwendung (in perl) die auf dem gleichen Server läuft. Ich hab mir die hosts date mal angesehen, die IPs stehen alle schon drin (oder sollte ich die besser in IPv6 angeben?). Ich hab die datei dann noch ein bisschen entrümpelt, das brachte aber auch keine Verbesserung.

 

[tuxedo]

Dann bau doch hier und da mal ein Paar Sysouts mit Zeitangaben ein. Wenn es nicht an der Netzwerkkommunikation liegt, muss der Fehler ja anderswo sein.

Wo kommen die Texte für die Übersetzung her? Platte? DB?

- Alex

 

[schebl]

Die Übersetzungen kommen aus einer Datenbank bzw. RAM (cache für häufig verwendete Übersetzungen). Sysouts brauche ich nicht, da ich Logwriter eingebaut habe, sowohl auf Java seite als auch in dem perl client. Darum kann ich auch ziemlich genau sagen wo die zeit auf der Strecke bleibt, und zwarch, nach abgeschlossenem Verbindungsaufbau. Und der Zeitverlust steigt analog zur anzahl der zu übersetzenden Begriffe, also ist es kein Pro-Verbindung-Problem, sondern ein Pro-Übersetzung-Problem. An der ermittlung der Übersetzung liegt es auch nicht, die ist blitz schnell, aber dann dauert es eben bis diese Übersetzung beim client angekommen ist.

 

[tuxedo]

Na dann sollte es doch für dich ein leichtes sein mit dem Logwriter die "schuldige" Programmzeile oder den schuldigen Programmabschnitt eingrenzen zu können bis du den verursacher gefunden hast, oder nicht?

Wie groß hast du denn den Netzwerkpuffer gewählt? Verwendest du "flush()"? Wie sieht denn deine "versenden" Routine aus?

- Alex

 

[schebl]

Ich sag ja, der schuldige sitzt irgendwo zwischen absetzen der Anfrage, und empfangen der Antwort, da sich dieser Prozess allerdings auf 2 verschiedene Umgebungen verteilt (perl und Java) und ich nicht weiß wie ich eine verteilete Zeitmessung realisieren soll, weiß ich nicht ob es der Frage- oder Antwortvorgang ist. Ich weiß nur das es die Datenbank- (bzw. Hash-) abfrage nicht ist.
Den Rat mit dem flush() habe ich in einem anderen Forum bereits bekommen und ein flush nach jedem writeLine eingefügt doch auch das brachte nichts. Meine "versenden" Routine sieht folgendermaßen aus:

  public void write(String messageString) throws IOException {
    if (messageString != null) {
      try {
        ByteBuffer transferBuffer = this.charsetEncoder.encode(CharBuffer.wrap(messageString));
        this.socketChannel.write(transferBuffer);
        this.socketChannel.socket().getOutputStream().flush();
      }
      catch (CharacterCodingException cce) {
        Debug.logError(cce);
      }
    }
  }

Zum Tema Netzwerkpuffer muß ich zu meiner Schande sagen "Was ist das" ;-) Nein, mal im Ernst, ich kann mir vorstellen was das ist, aber ich weiß nicht wie ich bei einem SocketChannel den puffer verstelle, dass das überhaupt notwendig ist und welche Werte da sinnvoll währen

 

[tuxedo]

Mach doch testweise mal ne Log-Ausgabe der Systemzeit in vor Zeile 4 und nach Zeile 6 ...

- ALex

 

[schebl]

Guter hinweis, danke. Jetzt weiß ich zumindest schon mal das die Zeit auf dem Weg von perl zu Java (Anfrage) liegen bleibt und nicht auf dem Rückweg. Beim Antworten ist die Linux Mühle sogar um einiges schneller (ca 3x). Nur weiß ich immer noch nicht warum.

 

[tuxedo]

Zeig mal den Teil der auf Java-Seite die Anfrage entgegeb nimmt?
Und wie sieht auf Perl-Seite das Senden aus?

Java verwendet, wie sicher Perl auch, einen Sendepuffer. Wenn der zu groß ist, und die Anfrage zu klein ist, dann wird die auf Perl-Seite gepufferte Anfrage nicht unbedingt _sofort_ gesendet. Perl müsste aber, wie Java auch, einen Befehl haben, mit dem man das leeren, sprich absenden des Pufferinhalts erzwingen kann.

Ist halt nur die Frage warum es bei Windows keine Probleme gab?

- Alex

 

[schebl]

OK, als ich diese Frage beantworten wollte, fiel mir auf das ich da doch sehr umständlich herangegangen bin. Ich habe meinen Server jetzt erstmal ein wenig umgeschrieben, wodurch er auch schon um einiges schneller geworden ist. Leider besteht die Geschwindigkeitsdifferenz zwischen Windows und Linux immernoch. Aber jetzt gehe ich erst mal in Weihnachtsferien. Ich hoffe wir können diese Diskussion im Januar fortführen.

 

[tuxedo]

Klar. Interessiert mich auch warum es da einen Unterschied gibt.

- Alex

 

[schebl]

Ich habe den Schuldigen, es liegt nicht an der Socketverbindung, oder sonst irgend einer hochtrabenden Java Technologie sondern an der primitiven einfachen sleep Anweisung. Das sich Java nicht so besonders an Zeitvorgaben hält wusste ich ja, aber das da solche unterschiede entstehen... sleep(0, 500000) dauert auf einem Windows Rechner im schnitt 1,9ms und auf einem Linux Rechner 7,9ms
Jetzt habe eich nur ein neues Problem, egal was ich angebe, ich bekomme die Schlafzeit nicht unter 7,9ms gedrückt. Ich könnte natürlich das sleep einfach rausnehmen, läuft auch gut und blitz schnell, solange alles reibungslos funktioniert, doch wenn der Client mal hängen bleibt, konsumiert mein Programm 100% Leistung eines Prozessors ohne irgendwas zu tun.

 

[tuxedo]

Jupp, das hätte ich dir gleich sagen können. Sleepzeiten sind unter windows und linux nicht gleich lang. Ist OS abhängig. Hat Sun auch irgendwo dokumentiert.

Zeig doch mal ein paar Zeilen um dein sleep() drum rum. Vielleicht lässt sich das ja anders lösen.

Soweit ich jetzt gelesen hab sollen die Timer der JVM in Linux genauer sein als unter Windows....

 

[Ark]

Soweit ich jetzt gelesen hab sollen die Timer der JVM in Linux genauer sein als unter Windows....

Ich baute vor langer Zeit mal eine kleine Stoppuhr, die neben ihrer eigentlichen Funktion auch anzeigen kann, wie genau sie die Zeit überhaupt messen kann. Ich staunte tatsächlich nicht schlecht, als ich feststellen musste, dass ich mich unter Windows im 100stel-, unter Linux aber im 1000stelbereich bewegte! :shock:

--> Linux ist einfach das bessere System.

Ark

 

[schebl]

Auf die Schnelle, die read methode in der das Nickerchen vorkommt:

  public String read() throws MalformedInputException, CharacterCodingException, IOException {
    if (!this.isInterrupted()) {
      ByteBuffer buffer = ByteBuffer.allocate(1024);
      while (!this.isInterrupted()) {
        if ((this.socketChannel.read(buffer)) < 0) {
          this.interrupt();
          throw new IOException();
        }
        if (buffer.position() > 0) {
          buffer.flip();
          this.lineBuffer.append(this.charsetDecoder.decode(buffer).toString());
          buffer.clear();
        }
        if (this.lineBuffer.length() > 0) {
          if (this.stopBytes == null) {
            if (this.lineBuffer.indexOf(STOPBYTES_CR) != -1) this.stopBytes = STOPBYTES_CR;
            else if (this.lineBuffer.indexOf(STOPBYTES_CRLF) != -1) this.stopBytes = STOPBYTES_CRLF;
            else if (this.lineBuffer.indexOf(STOPBYTES_LF) != -1) this.stopBytes = STOPBYTES_LF;
          }
          if (this.stopBytes != null && this.lineBuffer.indexOf(this.stopBytes) != -1) {
            String messageString = this.lineBuffer.substring(0, this.lineBuffer.indexOf(this.stopBytes));
            this.lineBuffer.delete(0, (this.lineBuffer.indexOf(this.stopBytes) + this.stopBytes.length()));
            messageString = messageString.trim();
            if (messageString.equals("")) return null;
            return (messageString);
          }
        }
        try {
          sleep(0, this.sleepTime);
        }
        catch (InterruptedException irqe) {
          throw new IOException();
        }
      }
    }
    throw new IOException();
  }

 

[tuxedo]

@Schebl

Bau doch einfach ein Flag ein das markiert, ob in der While-Schleife gearbeitet wurde (d.h. ob eine oder mehrere der IF-Bedingungen erfüllt wurden). Dann weißt du ob du schlafen musst oder nicht.

Wäre jetzt mein erster naiver Ansatz ...

Was ich allerdings nicht so ganz verstehe:

Wieso baust du auf Non-Blocking IO? So ein simples "Frage-Antwort-Spiel" wäre doch ideal für blocking IO. Oder hast du mehr als 10 oder sogar 100 Anfragen pro Sekunde?

Auf der anderen Seite:

Wieso machst du das beenden deiner read() Methode abhängig von der Laufzeit eines Threads? Macht man sowas nicht typischerweise in der run() Methode?
Wie dem auch sei:

Soweit ich weiß kann man Non-Blocking-IO auch "Event-Driven" machen... Kann dir da aber keine weiteren Coding-Tipps geben da ich NIO selbst noch nicht wirklich benutzt hab.

Tippe aber darauf dass sich dein sleep-Problem durch eine Verbesserung des Programmdesigns lösen lässt und sleep() dann ganz wegfällt.

- Alex

 

[schebl]

Fragen über fragen ;-) das "Frage-Antwort-Spiel" mache ich wahrscheinlich aus Blödhit ;-) weil ich mich mit NIO noch nicht so richtig auskenne, das ist halt ne Mischung aus neuer Technologie, und angestaubter programmierweise (wie du schon bemerktest ) ).
Das mit den 100 Anfragen pro Sekunde kann schon hinkommen, wenn so ein perl Script sich connected, und dann seinen Inhalt übersetzt haben will, da kommen schon mal 1 bis 3 hundert Keywords pro Seite zusammen, uns die sollten idealre weise unter einer Sekunde abgearbeitet sein.
das mit dem Flag wird nicht viel bringen, denn ich vermute das die Zeit nicht während eines Lesezyklus drauf geht, sondern bei der Reaktionszeit der read Anweisung. Trotzdem hast du mich da auf einen Gedanken gebracht, beziehungsweise einen alten Gedanken vervollständigt. Ich werde mal ein Bisschen mit Flags, Timeouts und Delayzeiten rumexperimentieren. Danke erstmal für den Denkanstoß.

 

[tuxedo]

Ähm, noch ne Sache...

Wenn du schon bis zu 300 Keywords übersetzt haben willst: Wieso machst du dann keine Sammelabfrage?

Klingt irgendwie stupide wenn dein Tool für jedes einzelne Wort eines Dokuments oder einer Seite (weiß ja nicht was da wirklich dran hängt) eine eigene Verbindung zum Java-Programm braucht.

Kannst du denn die zu übersetzenden Wörter nicht sammeln und gesammelt Java mitteilen?

- Alex

 

[schebl]

Nee, anders, einmal verbinden dann bis zu hundert Anfragen, und dann wieder trennen. Über richtige Sammelanfragen hab ich auch schon mal nachgedacht, währe aber ziemlich aufwändig, und würde meiner meinung nach den Aufwand nicht lohnen (zumal ich ja mitlerweile festgestellt habe das die Kommunikation an sich ziemlich schnell abläuft)
Mein Problem ist eher das ich eine Eierlegende Wollmilchsau programmieren will, eienen Server der von der manuellen Telnet anfrage bis zum high performance Script alles gleich gut bedienen kann. Ich sollte mich vielleicht auf eins festlegen.