[jcifs] Re: jCIFS throughput: what to expect?

Laurent Millet laurent.millet at airbus.com
Wed Jun 18 10:22:32 GMT 2008

Laurent Millet <laurent.millet <at> airbus.com> writes:
> > I would play with the snd_buf_size and rcv_buf_size properties maybe
> > (see the Overview page of the API documentation). To find the optimal
> > values you would have to look at a capture and verify that the
> > SMB_COM_{READ,WRITE}_ANDX packets are actually carrying full payloads
> > (as opposed to every other packet having a fragment which would
> > definitely kill performance).
> If the buffer size used to read data in Java code is big enough compared to
> [snd|rcv]_buf_size, I assume most payloads will be full and the last one a
> fragment. Is this correct?
> Anyway, I will check the packets on the wire.


For those of you that are interested, I've checked packets on the network. The
buffer size I use has an influence on the CIFS packets that are generated
(packet size is more or less capped by the snd_buf_size/rcv_buf_size value; the
value is not exactly the same, there seems to be some protocol overhead that
needs to be taken into account -- I haven't analyzed it further).

When the READ_ANDX/WRITE_ANDX packet is big enough, the TCP packet gets
fragmented. You can tweak the snd_buf_size/rcv_buf_size and java buffer size
values so that all fragments are full (up to MTU). However this is significant
only if the overall CIFS packet size is small. If you specify a buffer size that
is big enough, then the last fragment will not be a full TCP packet but as this
occurs only once in a while, overall throughput it still pretty good and
tweaking does not get you much further.

Hope this is clear enough :-)



More information about the jcifs mailing list