[Slightly OT?] Performance of SMB over WANs
Urban Widmark
urban at teststation.com
Fri Mar 1 04:41:03 GMT 2002
On Fri, 1 Mar 2002, Jason Haar wrote:
> Our company's WAN runs primarily over IPSec VPNs. Benchmarking shows
> Linux-to-Linux FTP/HTTP peaks at around 80% of the available Internet link
> over which the VPN operates - so that's looking pretty sweet.
>
> However, Microsoft networking runs at ***1/10th*** that amount! i.e. SMB
> transfers are a fraction of FTP transfer rates.
MS to MS?
> I originally thought this was a M$ stack issue, but then brought Samba in
> and benchmarked it on the same two Linux boxes used for the FTP tests - they
> had the same poor throughput.
>
> So, can anyone explain to me what's so different about SMB that would so
> radically affect it over a WAN link? I would have thought that after the
> initial auth/perms checks are done, the streaming of the data would approach
> FTP speeds...
HTTP is really simple, one request is all it takes to read a file, but SMB
can only transfer up to 64k in one message so it may need more
"signalling".
You should probably take a look at how the client is reading the file. Use
ethereal or similar.
If windows has any parameters to set for how readahead should be done you
may want to look at those.
If the linux smbfs client is involved in any of your tests then it is
expected that performance of raw transfers will be poor. It is doing
something like this:
read --->
<--- data (4k or less)
read --->
<--- data
read --->
<--- data
Which means that it waits for the reply to be fully read before requesting
the next page of data. It's bad enough on a 100Mbps LAN ...
But SMB allows multiplexing requests and it should be possible to do like
this:
read 1 --->
read 2 --->
...
read N --->
<--- data 1
<--- data 2
...
<--- data N
Possibly with the requests and responses overlapping.
Note that not everything requires downloading the whole file. A program
might mmap the file and then only the accessed parts are downloaded. So as
with all benchmarks the 1/10th figure isn't the whole truth.
/Urban
More information about the samba-technical
mailing list