From 556d1ca2d20c42c7ee5934631331f0a019203f06 Mon Sep 17 00:00:00 2001 From: Tim Potter Date: Fri, 22 Nov 2002 00:32:24 +0000 Subject: Sync docbook directory with HEAD. Sorry but there are way too many changes to track down all the commit messages and list them here. Most of the changes look like updates and cleanups from Jelmer though. (This used to be commit 75615648d0ace3bde6a2ef2dad562094f1b25d00) --- docs/docbook/projdoc/Speed.sgml | 238 +--------------------------------------- 1 file changed, 2 insertions(+), 236 deletions(-) (limited to 'docs/docbook/projdoc/Speed.sgml') diff --git a/docs/docbook/projdoc/Speed.sgml b/docs/docbook/projdoc/Speed.sgml index 17adf10429..55d8b9492b 100644 --- a/docs/docbook/projdoc/Speed.sgml +++ b/docs/docbook/projdoc/Speed.sgml @@ -53,92 +53,6 @@ systems. - -Oplocks - - -Overview - - -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. - - - - - -Level2 Oplocks - - -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 : - - - -level2 oplocks = true - - - -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. - - - - - -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 @@ -226,55 +140,6 @@ In most cases the default is the best option. - -Locking - - -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. - - - -The performance hit will probably be greater on NFS mounted -filesystems, but could be quite high even on local disks. - - - - - -Share modes - - -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". - - - -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 @@ -286,18 +151,6 @@ expensive. - -Wide lines - - -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. - - - - Read raw @@ -339,61 +192,6 @@ case you may wish to change this option. - -Read prediction - - -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. - - - -This is disabled by default. You can enable it by using "read -prediction = yes". - - - -Note that read prediction is only used on files that were opened read -only. - - - -Read prediction should particularly help for those silly clients (such -as "Write" under NT) which do lots of very small reads on a file. - - - -Samba will not read ahead more data than the amount specified in the -"read size" option. It always reads ahead on 1k block boundaries. - - - - - -Memory mapping - - -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 option -on the FLAGS line of the Makefile. - - - -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". - - - - Slow Clients @@ -510,11 +308,12 @@ drive (Kernel 2.0.30). The transfer rate was reasonable for 10 baseT. -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 + @@ -541,38 +340,5 @@ if it could get up to the rate of FTP the perfomance would be quite staggering. - - - -My Results - - -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. - - - -I get 490k/s on reading a 8Mb file with copy. -I get 441k/s writing the same file to the samba server. - - - -Of course, there's a lot more to benchmarks than 2 raw throughput -figures, but it gives you a ballpark figure. - - - -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 ... - - -- cgit