[jcifs] SmbFileInputStream performance issue
Allen, Michael B (RSCH)
Michael_B_Allen at ml.com
Mon Aug 12 11:36:24 EST 2002
Just out of curiosity, try taking out the out.write() from your code so that
you're measuring strictly the network and not the filesystem.
> -----Original Message-----
> From: Allen, Michael B (RSCH) [SMTP:Michael_B_Allen at ml.com]
> Sent: Sunday, August 11, 2002 9:26 PM
> To: 'andy chernow'
> Cc: 'jcifs at samba.org'
> Subject: RE: [jcifs] SmbFileInputStream performance issue
>
>
>
> > -----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