From 3d6bb1823c3a82958ee2b80be4f953e23703eb9d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 30 Apr 2003 21:26:24 +0000 Subject: Docbook XML conversion: projdoc (This used to be commit f7c9df751459da2d4a996d5f0135334fb3f87f69) --- docs/docbook/projdoc/Speed.xml | 211 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 docs/docbook/projdoc/Speed.xml (limited to 'docs/docbook/projdoc/Speed.xml') diff --git a/docs/docbook/projdoc/Speed.xml b/docs/docbook/projdoc/Speed.xml new file mode 100644 index 0000000000..2509883916 --- /dev/null +++ b/docs/docbook/projdoc/Speed.xml @@ -0,0 +1,211 @@ + + + + + PaulCochrane + + Dundee Limb Fitting Centre +
paulc@dth.scot.nhs.uk
+ + + &author.jelmer; + + +Samba performance issues + + +Comparisons + + +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. + + + +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. + + + +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. + + + +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. + + + + + +Socket options + + +There are a number of socket options that can greatly affect the +performance of a TCP based server like Samba. + + + +The socket options that Samba uses are settable both on the command +line with the -O option, or in the smb.conf file. + + + +The socket options section of the &smb.conf; manual page describes how +to set these and gives recommendations. + + + +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. + + + +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. + + + + + +Read size + + +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. + + + +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. + + + +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. + + + + + +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;. Note that this is the maximum size of SMB requests 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 +of less than 2048 is likely to cause severe problems. + + + +In most cases the default is the best option. + + + + + +Log level + + +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. + + + + +Read raw + + +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. + + + +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. + + + +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. + + + + + +Write raw + + +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. + + + +Some machines may find write raw slower than normal write, in which +case you may wish to change this option. + + + + + +Slow Logins + + +Slow logins are almost always due to the password checking time. Using +the lowest practical password level will improve things. + + + + + +Client tuning + + +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. Check the sections on the various clients in +Samba and Other Clients. + + + + -- cgit