[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