summaryrefslogtreecommitdiff
path: root/docs/textdocs/Speed.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/textdocs/Speed.txt')
-rw-r--r--docs/textdocs/Speed.txt83
1 files changed, 70 insertions, 13 deletions
diff --git a/docs/textdocs/Speed.txt b/docs/textdocs/Speed.txt
index 5dfd70323b1..fee111b6ec2 100644
--- a/docs/textdocs/Speed.txt
+++ b/docs/textdocs/Speed.txt
@@ -1,8 +1,14 @@
-This file tries to outline the ways to improve the speed of a Samba server.
+!==
+!== Speed.txt for Samba release 2.0.0-alpha11 09 Oct 1998
+!==
+Contributor: Andrew Tridgell
+Date: January 1995
+Status: Current
-Andrew Tridgell
-January 1995
+Subject: Samba performance issues
+============================================================================
+This file tries to outline the ways to improve the speed of a Samba server.
COMPARISONS
-----------
@@ -30,6 +36,47 @@ hardware Samba should certainly be competitive in speed with other
systems.
+OPLOCKS
+-------
+
+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.
+
+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 :
+
+oplocks = False
+
+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.
+
+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.
+
+Old 'fake oplocks' option - deprecated.
+---------------------------------------
+
+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.
+
+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.
+
SOCKET OPTIONS
--------------
@@ -80,7 +127,10 @@ MAX XMIT
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.
+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.
It defaults to 65536 bytes (the maximum), but it is possible that some
clients may perform better with a smaller transmit unit. Trying values
@@ -111,7 +161,20 @@ 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.
+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".
+
+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.
+
+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.
+
LOG LEVEL
---------
@@ -187,7 +250,7 @@ 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.
-To enable you you have to recompile Samba with the -DUSE_MMAP=1 option
+To enable you you have to recompile Samba with the -DUSE_MMAP option
on the FLAGS line of the Makefile.
Note that memory mapping is only used on files opened read only, and
@@ -239,6 +302,7 @@ person even reported a speed drop of a factor of 30 when he went from
It probably depends a lot on your hardware, and the type of unix box
you have at the other end of the link.
+
MY RESULTS
----------
@@ -263,10 +327,3 @@ smbclient running on another linux box. Maybe I'll add those results
here someday ...
-COMMENTS
---------
-
-If you've read this far then please give me some feedback! Which of
-the above suggestions worked for you?
-
-Mail the samba mailing list or samba-bugs@anu.edu.au