[jcifs] SmbFileInputStream performance issue
Allen, Michael B (RSCH)
Michael_B_Allen at ml.com
Mon Aug 12 11:26:21 EST 2002
> -----Original Message-----
> From: andy chernow [SMTP:achernow at yahoo.com]
> Sent: Sunday, August 11, 2002 8:25 PM
> To: Allen, Michael B (RSCH)
> Subject: RE: [jcifs] SmbFileInputStream performance issue
>
> Yes this is through the internet. When I am at the
> office on the same internal network as the server
> running samba, I see super fast speeds...100MBit
> network. The problem lies going through the internet,
> at least what I am seeing.
>
Unfortunately I don't really have a good way to test that scenario. I
could run Samba on a box on the internet but that's a little risky. I
suppose I could add the necessary rules to the filewall but that's an
ordeal.
> I tested transfers on an aDSL Modem and a Cable Modem.
> Both get an average download of 1.4Mbits. Cable
> seems to have bursts much higher on occasions. The
> upstreams are terrible, aDSL is 256Kbits and Cable is
> 128Kbits. An SSH session through putty or SecureCRT
> with an upstream of 16kbytes/sec gets pretty
> annoying:( Nothing like typing linux commands and
> waiting for them to appear.
>
> Okay, here is what I have done so far.
> Ran the Get.java. I downloaded a 1.72MB file from the
> server and Get.java printed out:
>
> 1812537 bytes transfered in 48 seconds at 37Kbytes/sec
>
Yes, that's disturbingly slow. But I know jCIFS can generate the
packets fast enough so something about the link has to be
different. Try reducing the rcv_buf_size to 800 and walk it up in 100
byte increments past 1600. The default for this property is 4166 but
minus the header this should always end up being 4096. The server
can negotiate a lower value. These buffers are chopped up by the
OS networking code to the MTU (max trans unit) which is 1500 on
LANs but very well could be 1000 on a PPP link. What I'm
wondering is this. If jCIFS and Samba negotiate a buffer size of say
1410 but the network MTU is 1400 what will happen is a packet of
1400 will be sent, and ACK will be revieved and then a whole-nother
SMB will be built just to send 10 bytes. Then 1400 and 10 again.
Then 1400, 10, 1400, 10, 1400, 10...and so on. This can effectively
cut your speed in half. In this case, if you set rcv_buf_size to 1400
+ header size of 70 - 10 to be safe = 1460 then on the wire this
would become 1390, 1390, 1390, 1390 .... which is much better.
Actually I just saw your trace. The packet sizes are 1460, 1460,
1239, 1460, 1460, 1239, ... which isn't so bad. At least you don't
have one read that's really small wasting a round trip.
You might also try setting the rcv_buf_size to something larger.
You might also try using a buffer in your code that's greater than
8192 like 32768.
I could be totally wrong about this but I think there is something
fishy going on in the OS networking layer at least. There's some
kind of delay. I don't see how it can be jCIFS considering we've
seen it run much faster. Is it possible you flipped on Tcp No Delay
in the VM by accedent?
Actually from the trace I can see there's a 10th of a second before
the ACK to the last packet in a read. On my LAN the time between
receiving the last request and sending the ACK packet for it is less
than 1 1000th of a second. If you read 1500000 bytes and wait 0.1
seconds every 4089 bytes that's 36 seconds. Daoh! There's your
problem right there. Win2K isn't sending the ACK's fast enough.
> This was on the Cable Modem where I usually see at
> least 100Kbytes/sec and as much as 400Kbytes/sec.
>
> I downloaded and installed ethereal on my win2k box
> but it apears to be very unhappy with win2k. No
> matter what I enter for the interface I get this error
> message
> "The capture session could not be initiated (Error
> opening adapter: the system could not find the file
> specified.). Please check that you have the proper
> interface specified.
>
> Note that the driver Ethereal uses for packet capture
> on Windows doesn't support capturing on PPP/WAN
> interfaces in Windows NT/2000"
>
> So I tried the linux server but that has no X
> installed becuase it is a server. About 20
> dependencies were listed trying to install the rpms.
> Would a printout of snort be okay, or even tcpdump???
> If so, is there a format you would prefer from either?
>
>
What we're interested in is the MTU of the link and
> Were the results from your 11MB in 15secs through the
> internet?
>
> /sLaKr
>
> --- "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com>
> wrote:
> > That's weird. Try the Get.java example from Win2K
> > and from the Linux
> > machine to Win2K and others. I just did this with
> > the latest code and I
> > transferred an 11 MB file in 15 seconds:
> >
> > [jcifs]$ java -Djcifs.properties=../miallen.prp Get
> > \
> >
> > smb://miallen2/pub/mozilla-win32-1.0-talkback.zip
> > 11224769 bytes transfered in 15 seconds at
> > 748Kbytes/sec
> >
> > Are you doing this on the Internet? Maybe it's a
> > strange MTU thing. You
> > might try experimenting with the
> > jcifs.smb.client.rcv_buf_size but if you
> > really* want to see what's happening quickly, run
> > Ethereal on one end with a
> > filter of "port 137 || port 139" during a transfer
> > and send the pcap to me
> > personally.
> >
> > > -----Original Message-----
> > > From: andy chernow [SMTP:achernow at yahoo.com]
> > > Sent: Sunday, August 11, 2002 6:29 PM
> > > To: jcifs at lists.samba.org
> > > Subject: [jcifs] SmbFileInputStream performance
> > issue
> > >
> > > I have a problem with the SmbFileInputStream and
> > how
> > > well it is performing. I am only able to to grab
> > a
> > > file from the server, using jCIFS, at ~25-35
> > > kilobytes/sec. Here is my setup and then I will
> > list
> > > my extremly simple code example.
> > >
> > > I have a RedHat 7.3 server running Samba2.2.5.
> > The
> > > server is on a T1 connection which is currently
> > only
> > > used by me. I have one user and one share setup
> > for
> > > accessing the samba server. Let's say the
> > username is
> > > 'foo', password is 'bar' and share is 'testshare'.
> >
> > >
> > > Simple test code. All tests performed on win2k
> > > accessing the same samba server!
> > >
> > > import java.io.*;
> > > import jcifs.smb.*;
> > >
> > > class test
> > > {
> > > static String url =
> > > "smb://foo:bar@hostname/testshare/file1.75MB.zip";
> > >
> > > public static void main(String[] args) throws
> > > Exception
> > > {
> > > FileOutputStream out = new
> > > FileOutputStream("file1.75MB.zip");
> > > SmbFileInputStream in = new
> > > SmbFileInputStream(url);
> > >
> > > // this is copied from jcifs site
> > > int n;
> > > byte[] buf = new byte[8192];
> > > while((n = in.read(buf)) != -1)
> > > out.write(buf, 0, n);
> > > out.close();
> > > in.close();
> > > }
> > > }
> > >
> > > For some reason, the above is always very slow.
> > > Cable Modem: ~36 kilobytes/second
> > > DSL Modem: ~30 kilobytes/second
> > >
> > > Now, if I map the share 'sharetest' on my Win2k
> > > machine as a Drive and then do a drag-n-drop of
> > > file1.75MB through standard windows mechanisms, it
> > > transfers at:
> > > Cable Modem: ~140 kilobytes/second
> > > DSL Modem: ~130 kilobytes/second
> > > This test removes the possiblity that the Samba
> > server
> > > has a poor config.
> > >
> > > Using OpenSSH SCP, both get ~150 kilobytes/second
> > > Using ProFTPD FTP, both get ~140 kilobytes/second
> > > Using Apache HTTP, both are ~125 kilobytes/second
> > >
> > > So why when I use SmbFileInputStream am I seeing
> > such
> > > a decrease in data transfer performance?
> > >
> > > I would appreciate any suggestions, I am currently
> > at
> > > a loss. Maybe I am missing something very simple.
> > >
> > > Thank you in advance,
> > > /sLaKr
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > HotJobs - Search Thousands of New Jobs
> > > http://www.hotjobs.com
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com
More information about the jcifs
mailing list