newly generated docs; removing old ones

(This used to be commit d72538fd14b8d00ea07f19464b4f3a3d93445cbf)
author: Gerald Carter <jerry@samba.org> 2002-10-02 14:08:40 +0000
committer: Gerald Carter <jerry@samba.org> 2002-10-02 14:08:40 +0000
commit: 53b16591832dc07e9e15a9078f08a899503bbaa6 (patch)
tree: f4f7d49b37c6289f94235a0056bd7aa0a3a23522 /docs/htmldocs/speed.html
parent: eb17f95e164520e0e5b0c665ad1ffc8323c7293f (diff)
download: samba-53b16591832dc07e9e15a9078f08a899503bbaa6.tar.gz
samba-53b16591832dc07e9e15a9078f08a899503bbaa6.tar.bz2
samba-53b16591832dc07e9e15a9078f08a899503bbaa6.zip
1 files changed, 616 insertions, 0 deletions
diff --git a/docs/htmldocs/speed.html b/docs/htmldocs/speed.html
new file mode 100644
index 0000000000..67843d6190
--- /dev/null
+++ b/docs/htmldocs/speed.html
@@ -0,0 +1,616 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<HTML
+><HEAD
+><TITLE
+>Samba performance issues</TITLE
+><META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
+"><LINK
+REL="HOME"
+TITLE="SAMBA Project Documentation"
+HREF="Samba-HOWTO.html"><LINK
+REL="PREVIOUS"
+TITLE="Improved browsing in samba"
+HREF="improved-browsing.html"><LINK
+REL="NEXT"
+TITLE="Samba and other CIFS clients"
+HREF="other-clients.html"></HEAD
+><BODY
+CLASS="CHAPTER"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="NAVHEADER"
+><TABLE
+SUMMARY="Header navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TH
+COLSPAN="3"
+ALIGN="center"
+>SAMBA Project Documentation</TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="improved-browsing.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="other-clients.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="CHAPTER"
+><H1
+><A
+NAME="SPEED">Chapter 16. Samba performance issues</H1
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2732">16.1. Comparisons</H1
+><P
+>The Samba server uses TCP to talk to the client. Thus if you are
+trying to see if it performs well you should really compare it to
+programs that use the same protocol. The most readily available
+programs for file transfer that use TCP are ftp or another TCP based
+SMB server.</P
+><P
+>If you want to test against something like a NT or WfWg server then
+you will have to disable all but TCP on either the client or
+server. Otherwise you may well be using a totally different protocol
+(such as Netbeui) and comparisons may not be valid.</P
+><P
+>Generally you should find that Samba performs similarly to ftp at raw
+transfer speed. It should perform quite a bit faster than NFS,
+although this very much depends on your system.</P
+><P
+>Several people have done comparisons between Samba and Novell, NFS or
+WinNT. In some cases Samba performed the best, in others the worst. I
+suspect the biggest factor is not Samba vs some other system but the
+hardware and drivers used on the various systems. Given similar
+hardware Samba should certainly be competitive in speed with other
+systems.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2738">16.2. Oplocks</H1
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN2740">16.2.1. Overview</H2
+><P
+>Oplocks are the way that SMB clients get permission from a server to
+locally cache file operations. If a server grants an oplock
+(opportunistic lock) then the client is free to assume that it is the
+only one accessing the file and it will agressively cache file
+data. With some oplock types the client may even cache file open/close
+operations. This can give enormous performance benefits.</P
+><P
+>With the release of Samba 1.9.18 we now correctly support opportunistic 
+locks. This is turned on by default, and can be turned off on a share-
+by-share basis by setting the parameter :</P
+><P
+><B
+CLASS="COMMAND"
+>oplocks = False</B
+></P
+><P
+>We recommend that you leave oplocks on however, as current benchmark
+tests with NetBench seem to give approximately a 30% improvement in
+speed with them on. This is on average however, and the actual 
+improvement seen can be orders of magnitude greater, depending on
+what the client redirector is doing.</P
+><P
+>Previous to Samba 1.9.18 there was a 'fake oplocks' option. This
+option has been left in the code for backwards compatibility reasons
+but it's use is now deprecated. A short summary of what the old
+code did follows.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN2748">16.2.2. Level2 Oplocks</H2
+><P
+>With Samba 2.0.5 a new capability - level2 (read only) oplocks is
+supported (although the option is off by default - see the smb.conf
+man page for details). Turning on level2 oplocks (on a share-by-share basis)
+by setting the parameter :</P
+><P
+><B
+CLASS="COMMAND"
+>level2 oplocks = true</B
+></P
+><P
+>should speed concurrent access to files that are not commonly written
+to, such as application serving shares (ie. shares that contain common
+.EXE files - such as a Microsoft Office share) as it allows clients to
+read-ahread cache copies of these files.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN2754">16.2.3. Old 'fake oplocks' option - deprecated</H2
+><P
+>Samba can also fake oplocks, by granting a oplock whenever a client 
+asks for one. This is controlled using the smb.conf option "fake 
+oplocks". If you set "fake oplocks = yes" then you are telling the 
+client that it may agressively cache the file data for all opens.</P
+><P
+>Enabling 'fake oplocks' on all read-only shares or shares that you know
+will only be accessed from one client at a time you will see a big
+performance improvement on many operations. If you enable this option
+on shares where multiple clients may be accessing the files read-write
+at the same time you can get data corruption.</P
+></DIV
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2758">16.3. Socket options</H1
+><P
+>There are a number of socket options that can greatly affect the
+performance of a TCP based server like Samba.</P
+><P
+>The socket options that Samba uses are settable both on the command
+line with the -O option, or in the smb.conf file.</P
+><P
+>The "socket options" section of the smb.conf manual page describes how
+to set these and gives recommendations.</P
+><P
+>Getting the socket options right can make a big difference to your
+performance, but getting them wrong can degrade it by just as
+much. The correct settings are very dependent on your local network.</P
+><P
+>The socket option TCP_NODELAY is the one that seems to make the
+biggest single difference for most networks. Many people report that
+adding "socket options = TCP_NODELAY" doubles the read performance of
+a Samba drive. The best explanation I have seen for this is that the
+Microsoft TCP/IP stack is slow in sending tcp ACKs.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2765">16.4. Read size</H1
+><P
+>The option "read size" affects the overlap of disk reads/writes with
+network reads/writes. If the amount of data being transferred in
+several of the SMB commands (currently SMBwrite, SMBwriteX and
+SMBreadbraw) is larger than this value then the server begins writing
+the data before it has received the whole packet from the network, or
+in the case of SMBreadbraw, it begins writing to the network before
+all the data has been read from disk.</P
+><P
+>This overlapping works best when the speeds of disk and network access
+are similar, having very little effect when the speed of one is much
+greater than the other.</P
+><P
+>The default value is 16384, but very little experimentation has been
+done yet to determine the optimal value, and it is likely that the best
+value will vary greatly between systems anyway. A value over 65536 is
+pointless and will cause you to allocate memory unnecessarily.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2770">16.5. Max xmit</H1
+><P
+>At startup the client and server negotiate a "maximum transmit" size,
+which limits the size of nearly all SMB commands. You can set the
+maximum size that Samba will negotiate using the "max xmit = " option
+in smb.conf. Note that this is the maximum size of SMB request that 
+Samba will accept, but not the maximum size that the *client* will accept.
+The client maximum receive size is sent to Samba by the client and Samba
+honours this limit.</P
+><P
+>It defaults to 65536 bytes (the maximum), but it is possible that some
+clients may perform better with a smaller transmit unit. Trying values
+of less than 2048 is likely to cause severe problems.</P
+><P
+>In most cases the default is the best option.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2775">16.6. Locking</H1
+><P
+>By default Samba does not implement strict locking on each read/write
+call (although it did in previous versions). If you enable strict
+locking (using "strict locking = yes") then you may find that you
+suffer a severe performance hit on some systems.</P
+><P
+>The performance hit will probably be greater on NFS mounted
+filesystems, but could be quite high even on local disks.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2779">16.7. Share modes</H1
+><P
+>Some people find that opening files is very slow. This is often
+because of the "share modes" code needed to fully implement the dos
+share modes stuff. You can disable this code using "share modes =
+no". This will gain you a lot in opening and closing files but will
+mean that (in some cases) the system won't force a second user of a
+file to open the file read-only if the first has it open
+read-write. For many applications that do their own locking this
+doesn't matter, but for some it may. Most Windows applications
+depend heavily on "share modes" working correctly and it is
+recommended that the Samba share mode support be left at the
+default of "on".</P
+><P
+>The share mode code in Samba has been re-written in the 1.9.17
+release following tests with the Ziff-Davis NetBench PC Benchmarking
+tool. It is now believed that Samba 1.9.17 implements share modes
+similarly to Windows NT.</P
+><P
+>NOTE: In the most recent versions of Samba there is an option to use
+shared memory via mmap() to implement the share modes. This makes
+things much faster. See the Makefile for how to enable this.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2784">16.8. Log level</H1
+><P
+>If you set the log level (also known as "debug level") higher than 2
+then you may suffer a large drop in performance. This is because the
+server flushes the log file after each operation, which can be very
+expensive. </P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2787">16.9. Wide lines</H1
+><P
+>The "wide links" option is now enabled by default, but if you disable
+it (for better security) then you may suffer a performance hit in
+resolving filenames. The performance loss is lessened if you have
+"getwd cache = yes", which is now the default.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2790">16.10. Read raw</H1
+><P
+>The "read raw" operation is designed to be an optimised, low-latency
+file read operation. A server may choose to not support it,
+however. and Samba makes support for "read raw" optional, with it
+being enabled by default.</P
+><P
+>In some cases clients don't handle "read raw" very well and actually
+get lower performance using it than they get using the conventional
+read operations. </P
+><P
+>So you might like to try "read raw = no" and see what happens on your
+network. It might lower, raise or not affect your performance. Only
+testing can really tell.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2795">16.11. Write raw</H1
+><P
+>The "write raw" operation is designed to be an optimised, low-latency
+file write operation. A server may choose to not support it,
+however. and Samba makes support for "write raw" optional, with it
+being enabled by default.</P
+><P
+>Some machines may find "write raw" slower than normal write, in which
+case you may wish to change this option.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2799">16.12. Read prediction</H1
+><P
+>Samba can do read prediction on some of the SMB commands. Read
+prediction means that Samba reads some extra data on the last file it
+read while waiting for the next SMB command to arrive. It can then
+respond more quickly when the next read request arrives.</P
+><P
+>This is disabled by default. You can enable it by using "read
+prediction = yes".</P
+><P
+>Note that read prediction is only used on files that were opened read
+only.</P
+><P
+>Read prediction should particularly help for those silly clients (such
+as "Write" under NT) which do lots of very small reads on a file.</P
+><P
+>Samba will not read ahead more data than the amount specified in the
+"read size" option. It always reads ahead on 1k block boundaries.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2806">16.13. Memory mapping</H1
+><P
+>Samba supports reading files via memory mapping them. One some
+machines this can give a large boost to performance, on others it
+makes not difference at all, and on some it may reduce performance.</P
+><P
+>To enable you you have to recompile Samba with the -DUSE_MMAP option
+on the FLAGS line of the Makefile.</P
+><P
+>Note that memory mapping is only used on files opened read only, and
+is not used by the "read raw" operation. Thus you may find memory
+mapping is more effective if you disable "read raw" using "read raw =
+no".</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2811">16.14. Slow Clients</H1
+><P
+>One person has reported that setting the protocol to COREPLUS rather
+than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s).</P
+><P
+>I suspect that his PC's (386sx16 based) were asking for more data than
+they could chew. I suspect a similar speed could be had by setting
+"read raw = no" and "max xmit = 2048", instead of changing the
+protocol. Lowering the "read size" might also help.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2815">16.15. Slow Logins</H1
+><P
+>Slow logins are almost always due to the password checking time. Using
+the lowest practical "password level" will improve things a lot. You
+could also enable the "UFC crypt" option in the Makefile.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2818">16.16. Client tuning</H1
+><P
+>Often a speed problem can be traced to the client. The client (for
+example Windows for Workgroups) can often be tuned for better TCP
+performance.</P
+><P
+>See your client docs for details. In particular, I have heard rumours
+that the WfWg options TCPWINDOWSIZE and TCPSEGMENTSIZE can have a
+large impact on performance.</P
+><P
+>Also note that some people have found that setting DefaultRcvWindow in
+the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a
+big improvement. I don't know why.</P
+><P
+>My own experience wth DefaultRcvWindow is that I get much better
+performance with a large value (16384 or larger). Other people have
+reported that anything over 3072 slows things down enourmously. One
+person even reported a speed drop of a factor of 30 when he went from
+3072 to 8192. I don't know why.</P
+><P
+>It probably depends a lot on your hardware, and the type of unix box
+you have at the other end of the link.</P
+><P
+>Paul Cochrane has done some testing on client side tuning and come 
+to the following conclusions:</P
+><P
+>Install the W2setup.exe file from www.microsoft.com. This is an 
+update for the winsock stack and utilities which improve performance.</P
+><P
+>Configure the win95 TCPIP registry settings to give better 
+perfomance. I use a program called MTUSPEED.exe which I got off the 
+net. There are various other utilities of this type freely available. 
+The setting which give the best performance for me are:</P
+><P
+></P
+><OL
+TYPE="1"
+><LI
+><P
+>MaxMTU                  Remove</P
+></LI
+><LI
+><P
+>RWIN                    Remove</P
+></LI
+><LI
+><P
+>MTUAutoDiscover         Disable</P
+></LI
+><LI
+><P
+>MTUBlackHoleDetect      Disable</P
+></LI
+><LI
+><P
+>Time To Live            Enabled</P
+></LI
+><LI
+><P
+>Time To Live - HOPS     32</P
+></LI
+><LI
+><P
+>NDI Cache Size          0</P
+></LI
+></OL
+><P
+>I tried virtually all of the items mentioned in the document and 
+the only one which made a difference to me was the socket options. It 
+turned out I was better off without any!!!!!</P
+><P
+>In terms of overall speed of transfer, between various win95 clients 
+and a DX2-66 20MB server with a crappy NE2000 compatible and old IDE 
+drive (Kernel 2.0.30). The transfer rate was reasonable for 10 baseT.</P
+><P
+>FIXME
+The figures are:          Put              Get 
+P166 client 3Com card:    420-440kB/s      500-520kB/s
+P100 client 3Com card:    390-410kB/s      490-510kB/s
+DX4-75 client NE2000:     370-380kB/s      330-350kB/s</P
+><P
+>I based these test on transfer two files a 4.5MB text file and a 15MB 
+textfile. The results arn't bad considering the hardware Samba is 
+running on. It's a crap machine!!!!</P
+><P
+>The updates mentioned in 1 and 2 brought up the transfer rates from 
+just over 100kB/s in some clients.</P
+><P
+>A new client is a P333 connected via a 100MB/s card and hub. The 
+transfer rates from this were good: 450-500kB/s on put and 600+kB/s 
+on get.</P
+><P
+>Looking at standard FTP throughput, Samba is a bit slower (100kB/s 
+upwards). I suppose there is more going on in the samba protocol, but 
+if it could get up to the rate of FTP the perfomance would be quite 
+staggering.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2850">16.17. My Results</H1
+><P
+>Some people want to see real numbers in a document like this, so here
+they are. I have a 486sx33 client running WfWg 3.11 with the 3.11b
+tcp/ip stack. It has a slow IDE drive and 20Mb of ram. It has a SMC
+Elite-16 ISA bus ethernet card. The only WfWg tuning I've done is to
+set DefaultRcvWindow in the [MSTCP] section of system.ini to 16384. My
+server is a 486dx3-66 running Linux. It also has 20Mb of ram and a SMC
+Elite-16 card. You can see my server config in the examples/tridge/
+subdirectory of the distribution.</P
+><P
+>I get 490k/s on reading a 8Mb file with copy.
+I get 441k/s writing the same file to the samba server.</P
+><P
+>Of course, there's a lot more to benchmarks than 2 raw throughput
+figures, but it gives you a ballpark figure.</P
+><P
+>I've also tested Win95 and WinNT, and found WinNT gave me the best
+speed as a samba client. The fastest client of all (for me) is
+smbclient running on another linux box. Maybe I'll add those results
+here someday ...</P
+></DIV
+></DIV
+><DIV
+CLASS="NAVFOOTER"
+><HR
+ALIGN="LEFT"
+WIDTH="100%"><TABLE
+SUMMARY="Footer navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+><A
+HREF="improved-browsing.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="Samba-HOWTO.html"
+ACCESSKEY="H"
+>Home</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+><A
+HREF="other-clients.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>Improved browsing in samba</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+>&nbsp;</TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Samba and other CIFS clients</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
+\ No newline at end of file
author	Gerald Carter <jerry@samba.org>	2002-10-02 14:08:40 +0000
committer	Gerald Carter <jerry@samba.org>	2002-10-02 14:08:40 +0000
commit	53b16591832dc07e9e15a9078f08a899503bbaa6 (patch)
tree	f4f7d49b37c6289f94235a0056bd7aa0a3a23522 /docs/htmldocs/speed.html
parent	eb17f95e164520e0e5b0c665ad1ffc8323c7293f (diff)
download	samba-53b16591832dc07e9e15a9078f08a899503bbaa6.tar.gz samba-53b16591832dc07e9e15a9078f08a899503bbaa6.tar.bz2 samba-53b16591832dc07e9e15a9078f08a899503bbaa6.zip