[jcifs] SmbFileInputStream performance issue

Allen, Michael B (RSCH) Michael_B_Allen at ml.com
Mon Aug 12 12:44:52 EST 2002


> -----Original Message-----
> From:	andy chernow [SMTP:achernow at yahoo.com]
> Sent:	Sunday, August 11, 2002 9:56 PM
> To:	Allen, Michael B (RSCH)
> Subject:	RE: [jcifs] SmbFileInputStream performance issue
> 
> >try taking out the out.write()
> I tried that one, no luck there.
> 
> What did work is setting the recv_buf_size to an
> enourmously high value, 262144.  Then I set the byte[]
> buf to 131072.  This gave me this print out from
> Get.java:
> 
	This will basically result in negotiating the higest possible value
	which may be as much as 64k. Actually to be precise I think the
	higest possible value for rcv_buf_size is 0xFFFF + 70. Anyway,
	based on that 0.1 second latency this will result in only an extra 2
	seconds opposed to the 36 seconds I calculated before. Much
	better. Also, use a buffer of 64536 in your code. Anything above that
	is just wasting memory.

	Incedentally if you will be writing too, there's a
	jcifs.smb.client.snd_buf_size that for whatever reason I don't think
	is documented anywhere. I seem to recall writes going down the
	tubes if this property wasn't 1300 for some reason. That's probably
	why it's not in the docs. In your case it might have an opposite
	effect. You'd have to experiment.

> 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 gave you a way to test this.  You can use this url:
> 
	Firewall is anal both ways. Maybe some other time, but looks
	like your problem is solved. Although the 0.1s latency is still there;
	I'm not sure if that matters with your app.

> I setup a user for you:
> 
> If you want a larger file just ask.  This network is
> bone dry of traffic right now.  It's a start-up with
> another few months of pure development.  You would be
> grabbing this file from a full uncapped T1.
> 
> By the way, how do I know if tcp no delay is switch on
> within the VM.  I never set this on the VM and thought
> this was just a per Socket basis setting.
> 
	True. It is controlled at the socket level. I was just stabbing in the
	dark. Buffersize appears to be the issue after all. I will have to
	increase the default and add a little message to the API overview.
	Stangely I recall transfers suffered slightly when I had the
	rcv_buf_size higher.

> /sLaKr
> 
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com




More information about the jcifs mailing list