Performance Problem mit File-I/O

[egrath]

Hallo,

ich habe ein kleines Performanceproblem mit der File Klasse. Aber kurz einmal die vorgeschichte damit man weiss um was es geht:

1.) Ich habe einen Ordner in dem pro Tag von einer Fremdapplikation ~10.000 Dateien (in diversen Unterverzeichnissen) abgestellt werden
2.) Dieser Ordner befindet sich auf einem Netzlaufwerk.
3.) Diese Dateien soll ich in ein Zip Archiv packen und das original löschen.

Ich erstelle mir nun eine Liste aller Dateien die ich zu archivieren habe. Um Informationen über die Datei zu bekommen benutze ich die File Klasse (Name, Letztes Modifikationsdatum, etc.). Und hier liegt der Hund begraben: Für die Abfrage des letzten Modifikationsdatums (lastModified) und ob es sich um ein File handelt (isFile) benötige ich pro Datei 30ms - kommt mir schon etwas lang vor.

Ein noch gravierenderes Performanceproblem habe ich anschliessend beim archivieren: Das Lesen einer einzelnen Datei dauert ca. 2-3 sekunden, obwohl das File gerade mal ~2k gross ist. Folgenden Code benutze ich dabei:

    public boolean addFile( String filePath, String fileName, String pathInZip )
    throws FileNotFoundException, IOException
    {
        debug_.printMessage( "ZipArchiver.addFile(): Adding to ZIP [" + filePath + "]" );
        FileInputStream inStream = new FileInputStream( filePath );
        zipStream_.putNextEntry( new ZipEntry( MessageFormat.format( "{0}{1}", pathInZip, fileName )));
        
        int len = 0;
        byte[] buffer = new byte[readBlockSize_];
        while(( len = inStream.read( buffer )) > 0 )
        {
            zipStream_.write( buffer, 0, len );
        }
        
        zipStream_.closeEntry();
       
        return true;
    }

Das Problem tritt nur über Netzlaufwerke auf, lokal ist das ganze rasend schnell.

Irgendjemand ne idee?

Danke,
Egon

 

[DP]

antivirus?

 

[egrath]

Hallo,

danke mal für die Anregung hab ich gerade eben probiert (auf beiden Seiten deaktiviert): Keine Besserung

Ich denke daher dass es irgendetwas damit zu tun haben muss wie die File Klasse intern arbeitet.... naja noch etwas rumexperimentieren vielleicht krieg ich es noch hin.

Grüsse,
Egon

 

[tuxedo]

Netzlaufwerke (CIFS/Samba-Share) sind nicht die schnellsten. 30ms Latenz um ein "lastModified" nachzuschlagen halte ich da schon für recht schnell. Und generell gilt bei sowas: Je kleiner die Datei, desto schlimmer ist das mit dem lesen/verschicken (Stichwort Puffer und ein passendes flush()). Kann mir nicht vorstellen dass Java daran schuld ist wenns lokal 1a geht.

Als WorkAround fällt mir nur eins ein (hab aber kein Plan ob das wirklich schneller wird):

Bastle nen Java-Server auf den Rechner der die Dateien vorhält und greife mit deinem Pack-Programm auf diesen Server zu. So hast du wenigstens einfluss auf die Puffergrößen, abschaltung des Nagle-Algorithmus' etc. Verwende hierzu am besten Java NIO, sowohl im Netzwerk-Part, als auch im File-lesen-und-schreiben-Part.


- Alex

 

[egrath]

Hallo,

ok danke für die Info, dann werd ich mal schauen ob ich das Ding nicht gleich lokal auf dem Server laufen lasse!

Grüsse,
Egon

 

[tuxedo]

Das wäre wohl die geschickteste Lösung ;-)

 

[Gast]

mußt du inStream eigentlich schließen?

nicht das du dich zumüllst.

Kann es evtl. vorteilhafter sein den FileInputStream in einen BufferedInputStream zu packen.