From 2b799b56f4d37d2baec44088c096a5a34ac8a968 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Thu, 14 Nov 2002 21:36:46 +0000 Subject: Remove some obsolete info (This used to be commit ffd2d3a0ba56f967112aaa63efd4221fad2cee70) --- 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