Dan Allen published very interesting article , related to XenApp and file server communications. Actually, this article explains the SMB default settings limitations and gives an advice how to improve performance of any Windows file server. I have copied the first part of this article and added an example of .reg file, which you can use to tune-up your file server.
SMB Tuning for XenApp and File Servers on Windows Server 2008
By Dan Allen · Published October 21, 2010
I have received a lot of questions from customers lately on whether there is a need to tune Windows Server 2008 file servers, especially if the client machines connecting to them are capable of using SMB 2.0, which includes Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. Unfortunately, there is not much information out there on this topic, so I decided to do a little research and testing for myself.
The SMB 1.0 Problem
To begin, it is important to understand the SMB 1.0 limitation that has been present since we first started implementing Terminal Server deployments back in the good old days of NT and MetaFrame. There have already been a lot of good SMB tuning articles out there that discuss this in detail, so I will not go into too much of an extensive discussion here, but I will summarize.
When a client computer using SMB 1.0 (NT 4.0, 2000, XP, 2003, etc…) attempts to connect to a Windows file server, it will query the file server and ask how many concurrent network (SMB) commands it can have submitted and open simultaneously. The file server will respond with a number and the network redirector on the client computer will limit itself to the number provided by the file server. The number that the file server provides is controlled by the SMB value for Max Mpx Count, which is set by the following registry entry on Windows file servers:
By default, this value does not exist on a Windows Server. If it does not exist, the Operating System uses a default value of 50.
This means that an individual client computer will not be able to have more than 50 simultaneous SMB commands to the file server. An SMB command can be anything from a directory listing, file creation, deletion, ACL manipulation, etc… basically, any kind of file or directory access.
The 50 command limitation quickly becomes a problem on a Terminal Server because there is only one redirector that is shared by all users on the server. In a typical Terminal Server environment, often users will all connect to the same file server for home directories, roaming profiles and redirected folders. This means that each user could easily be generating multiple SMB commands to a single file server. Once you start loading 50+ users on the server, you can easily have more than 50 outstanding SMB commands that need to be serviced, especially if folder redirection is being used. Since only 50 get serviced at one time, the rest of the commands begin to queue up and wait for servicing. This can cause poor performance or even application failures as applications make file requests that time out waiting to be serviced.
A workstation or SMB Client may make a request to have more than 50 SMB commands simultaneously open to a file server; however, if the file server has not been tuned, the client will not use more than the Max Mpx Count returned by the file server. The maximum number of simultaneous requests that a workstation will attempt to use is controlled by the Maximum Commands SMB setting defined by the following registry entry on the client:
By default this value is also 50 if it is not defined. So to properly tune an environment for maximum density of Terminal Server/XenApp users, you must add the MaxCmds key to all Terminal Serves and the MaxMpxCt key to all file servers. We have typically recommended increasing these entries to a decimal value of 2048.
Microsoft has a good article (324446) that has been around since Windows 2000 that discusses this issue and recommends the follow registry keys that should be implemented on file servers being accessed by Terminal Servers:
“MaxWorkItems”=dword:00002000 (decimal 8192)
“MaxMpxCt”=dword:00000800 (decimal 2048)
“MaxRawWorkItems”=dword:00000200 (decimal 512)
“MaxFreeConnections”=dword:00000064 (decimal 100)
“MinFreeConnections”=dword:00000020 (decimal 32)
It is also important to note that this issue and these registry keys are fully applicable to Terminal Servers and File Servers running the x64 edition of Window Server 2003. This is not a 32-bit problem, but rather an SMB problem.
In addition to the above registry tuning, there was another SMB client fix which reduces the SMB chatter and SMB commands that are opened from a client to a file server. This registry setting is one that we recommend be implemented on all XenApp Servers:
You can verify whether or not your system has excessive SMB commands being queued by reviewing the following performance monitor counter on your XenApp servers: Redirector/Current Commands. If this counter gets close to 50 and you have not tuned your file servers, then you definitely have a problem.
Here are some Microsoft articles for reference:
I have just compiled the settings that Dan mentioned in his article into one, ready-to-use .reg file
Windows Registry Editor Version 5.00