[jcifs] SmbFileInputStream performance issue

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	andy chernow [SMTP:achernow at yahoo.com]
> Sent:	Monday, August 12, 2002 12:14 AM
> To:	Allen, Michael B (RSCH)
> Subject:	RE: [jcifs] SmbFileInputStream performance issue
> 
> > > 1812537 bytes transfered in 14 seconds at
> > > 129Kbytes/sec
> > > 
> > > That seems like very high numbers.
> > > 
> > 	What is? 129Kbytes/sec? I thought that's right
> > around what you
> > 	were seeing from the other clients?
> 
> I meant the values I used for rcv_buf_size and the
> byte[] seemed very high or unusual.  I just cranked it
> forgetting bigger is not always better.  
> 
> Using your suggestions for the byte[] at 64536 and the
> rcv_buf_size at 0xFFFF + 70, 65605, I got the best
> results yet.
> 
> 1812537 bytes transfered in 13 seconds at
> 139Kbytes/sec
> 
> This out performs windows by 7 seconds.  My windows
> test was going Start|Run: \\hostname\share, and
> Drag-n-dropping the same file1.72MB.tar.gz to another
> window.  
> 
	You know, with 0.7 you can copyTo entire directories in literally
	*half* the time it takes Windows (although we don't copy file
	attributes which undoubtedly accounts for a good chunk of this
	performance differential).

> It maybe possible that the ACK delay has something to
> due with the bizarre Cable Modem network
> configuration, which is a large WAN.  Adelphia Cable
> isn't stocking the best network engineers.  It might
> not be win2k specifically.  I don't want to know the
> routing nightmare invovled in Adelphia's network.  I
> will test win95, 98, XP, ME and Linux to see if that
> .1 delay is still there and let you know.
> 
> THANK YOU!  
> 
> I should also thank you for your ideas in regards to
> the SSLNbtSocket.  You had advised me on that one back
> in June I think.  I told you it would be a while until
> I got to that phase.  I wrote that code about a week
> or 2 ago.  You were right, creating the SSLNbtSocket
> and adjusting SmbTransport was the easy part,
> certificates and keys are a pain in the a**.  I see no
> performance hit using the encryption and stunnel port
> forwarding.  The only bummer is creating the VM's
> first SecureRandom().  On my machine, P3 1Ghz 512MB
> RAM, this takes 5-6 seconds.  So before displaying my
> apps splash screen, I spawn a Thread to create the
> SecureRandom(), and the first smb request gets
> notified when the SecureRandom() is done: if not
> already.  Seems to work.
> 
> /sLaKr
> 
	Always good to hear success stories.

	Your welcome,
	Mike