[jcifs] Re: Large File upload performance
Michael B Allen
mba2000 at ioplex.com
Sat Sep 20 08:19:50 EST 2003
> Okay, I just did a simple test. I copied a 32MB file from one machine to
> another using SMBFS on the client side and Samba on the server side. It
> took 5minutes, 9seconds. Copying the same file to the same location using
> Put.java took 5minutes, 21seconds. The difference is small enough that it
> is likely to be the result of variations in network speed (this is over a
> cable modem link and it tends to have a lot of jitter).
> To be honest, the above doesn't tell us much. If there is a difference in
> software performance, it is likely to be drowned out by the slow network
> speed. If the problem that Naved is seeing has anything to do with
> protocol usage then my test does not provide any comparable data.
Actually I don't think this is a good test. The difference would be most
apparent on high speed low latency networks. JCIFS writes are actually
tuned to high latency slow networks because it uses a snd_buf_size below
the MTU so the ACK is piggy backed in the response (you can't tune it to
high speed low latency networks as Naved just demonstrated so we might as
well tune it for slow high latency networks). On low latency networks the
ACK doesn't matter so much and the buffer copy starts to show. At least I
think that's what's happening.
I will fix this eventually but for now I don't think there's anything
Naved can do about it unless he want's to change the writeWireFormat
offset from 0 to 4 to leave room for the NetBIOS header and then hack
NbtSocket to not do the copy and just encode the NetBIOS header in the new
4 byte space. It's ugly so I'm not going to do it but it would probably
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and, more important, to tasks that have not
yet been conceived.
More information about the jcifs