wget vs netty

Frederic Bregier fredbregier at free.fr
Sat Nov 7 16:04:16 EST 2009 

Hi David,

I've got a similar problem using write to file from Java in my project (FTP
using Netty).
In fact, it turns out that the problem has nothing related to Netty but of
course to JVM way to write files.

To be sure, I've done a little benchmark, trying several ways to read or
write files in Java without any network access. 

Here are some results, tested on 2.6.5-7.244-smp 2 cpu 2-core 2.8Ghz Xeon
using two JVM: Sun JDK 1.6.0.13 and IBM 1.6 SR5 (5/2009). 
Take them with caution since they must be used for what they are: testing
purpose for my scenario
Each wile is written, flushed (by the way available) then delete and
rewrited from scratch.

Write file:
- arbitrary position when write is starting (or restarting)
Note tha FileOutputStream is not allowed since in my scenario we can restart
a write from a previous position and FileOutputStream does not allowed to
change the position (except 0 or at the end at construction), except if we
used the FileChannel with the append mode and the position method of the
FileChannel.
   - RandomAccessFile : 10 MB files, 10 writes for each thread: 
     1 thread = around 40 MByte/s ; 50 threads = 3,32 MByte/s
     same but 1 MB files 10 times with 500 threads = 2,96 MByte/s (IBM JDK)
2.89 MByte/s (SUN JDK)

   - FileChannel over a RandomAccessFile : 10 MB files, 10 writes for each
thread: 
     1 thread = around 40 MByte/s; 50 threads = 3,33 MByte/s
     same but 1 MB files 10 times with 500 threads = 2,84 MByte/s (IBM JDK)
2,85 MByte/s (SUN JDK)

Note that most of the time, direct RandomAccessFile is faster than
FileChannel for me when more than 100 threads are concurrently writing
files.


- start from 0 or from end (append) (FileOutputStream is therefore allowed)
   - FileOutputStream : 10 MB files, 10 writes for each thread: 
     1 thread = around 250 MByte/s; 50 threads = 154,5 MByte/s
     same but 1 MB files 10 times with 500 threads = 25,94 MByte/s (IBM JDK)
27,42 MByte/s (SUN JDK)

  - FileChannel over FileOutputStream : 10 MB files, 10 writes for each
thread: 
     1 thread = around 40 MByte/s; 50 threads = 3,15 MByte/s
     same but 1 MB files 10 times with 500 threads = 2,82 MByte/s (IBM JDK)
2,83 MByte/s (SUN JDK)

  - BufferedOutputStream over FileOutputStream : 10 MB files, 10 writes for
each thread: 
     1 thread = 250 MByte/s; 50 threads = 183,3 MByte/s
     same but 1 MB files 10 times with 500 threads = 21,02 MByte/s (IBM JDK)
20,67 MByte/s (SUN JDK)


So FileOutputStream is the faster, Buffered one just under but not
FileChannel (same level and even a little bit worst than FileChannel based
on RandomAccessFile).
Note that Systems info shows that write speed on disk from system point of
view says it was about 3 to 4 MBytes/s whatever the test.

For my project, I need to be sure that I can move from one point to another,
so I need RandomAccess capability, so no chance for me to use
FileOutputStream directly.



Read File: Please note that as each thread access its own file but several
times, the system cache is used so the reason of huge performance in
reading.
- best is always : FileChannel over a FileInputStream :10 MB files, 10 reads
for each thread: 
     1 thread = 2 210 MByte/s; 50 threads = 3 329 MByte/s
     same but 1 MB files with 500 threads = 2 801 MByte/s (IBM JDK) 3 106
MByte/s (SUN JDK)

I do not show the others, but with many threads, FileChannel over
FileInputStream tends to be the best.


Hope this helps others too...

Cheers,
Frederic



Trustin Lee wrote:
> 
> Hi David,
> 
> Just to make sure disk I/O is not a bottleneck, could you try to
> configure wget and your Netty application to discard the received data
> to /dev/null?
> 
> I also wonder if you are using Netty's built-in HTTP codec or your own
> one.
> 
> — Trustin Lee, http://gleamynode.net/
> 
> On Sat, Nov 7, 2009 at 7:02 PM, Hoyt, David <hoyt6 at llnl.gov> wrote:
>> Our application does a lot of downloading -- I notice that when I test my
>> netty app against wget for some basic non-encrypted http streams, wget
>> outperforms my netty app. My basic test is I start 2 wget processes and
>> have them download some content from our server. I then have netty
>> download the same content. I give each 20 seconds to download as much as
>> they can and then I cancel it (the file contents are produced on-the-fly
>> at a constant rate of ~500 KB/s). wget consistently does better than my
>> java app (by ~3MB per file with 2 concurrent downloads). It's a bit
>> confusing, b/c my CPU is nowhere near maxed out using either wget or
>> netty (java). The discrepancy gets much higher when I start doing 10+
>> concurrent downloads. wget will download an 11 MB file while my java app
>> gets ~700-800 KB. Every message (http chunk) I get from netty is
>> immediately flushed to disk and I'm using a FileChannel for what I
>> figured was optimum performance. It should be able to do the full 11 MB
>> eve!
>>  n if it takes a little while for it to come in. 2 streams of 500 KB/s
>> (so ~ 1 MB/s) should be easily handled by java/netty I would think.
>>
>> I don't think I'm IO-bound - the disk can easily write ~22 MB (the file
>> is ~11 MB) and wget doesn't seem to have a problem writing to disk. I'm
>> on a gigabit line and 22 MB over 20 seconds shouldn't be saturating the
>> connection.
>>
>> I'm wondering if there's something I'm missing here. I'm following the
>> http examples pretty closely. I use keepAlive, reuseAddress, and
>> tcpNoDelay for the client bootstrap. I made the threads in my thread pool
>> have MAX_PRIORITY to help rule out scheduler issues. Everything else is
>> using the defaults.
>>
>> I did a quick old IO (OIO) implementation and it seemed to suffer more
>> than netty. I thought perhaps that something I was doing may have cut off
>> the content before it could be flushed to the disk, but using OIO and
>> input streams should have gotten the full content eventually.
>>
>> I could really use some help or some pointers on what the community does
>> for netty and/or network optimizations.
>>
>> I'm doing my testing on a Windows box but we'll be deploying for linux.
>> The behavior appears on both platforms (Windows XP and CentOS).
>>
>> Thanks,
>> - David Hoyt
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 


-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/Streaming-to-file-tp3959961p3965687.html
Sent from the Netty User Group mailing list archive at Nabble.com.

More information about the netty-users mailing list