File Server performance improvements with the SMB2 protocol in Windows Server 2008
SMB (Server Message Block) is the main protocol used in Windows for file sharing and it has been significantly improved from Windows Server 2003/Windows XP to Windows Server 2008/Windows Vista.
During my TechEd 2008 ITForum presentation on “Windows Server 2008 – File and Storage Solutions”, I covered some details on SMB2 and showed a demo of the improvement in file copy performance from SMB1 to SMB2.
The presentation highlighted the main changes in the new version of the protocol, including:
- Request pipelining allows multiple requests to be sent before receiving a response
- Larger reads and writes make better use of faster networks, even with high latency
- Request compounding, which allows multiple SMB requests to be sent as a single network request
- Caching of folder and file properties, where clients keeps local copy of information on folders and files
- Durable handles allow a stateful connection to be reestablished in case of network issues
- Much smaller opcode set reduces complexity of the protocol implementation and attack surface
- Message signing improved (HMAC SHA-256 replaces MD5 as hashing algorithm)
- Improved scalability for file sharing (number of users, shares and open files per server greatly increased)
All these lead to significant performance improvements for common scenarios like folder enumerations and file copies.
Three servers were used in the file copy demo, two of them running Windows Server 2008 and one using Windows 2003 Server.
The servers were called Client2008 (ip address 10.1.1.1), Server2008 (ip address 10.1.1.2) and Server2003 (ip address 10.1.1.3).
The copy between Client2008 and Server2003 used SMB1 while the copy between Client2008 and Server2008 used SMB2.
The demo consisted of opening the built-in Performance tool (perfmon.exe) in Client2008 to show the total bytes per second in the network interface while copying a 17MB file to Server2008 and then Server2003.
This was first done on a network with around 60ms round trip time and later repeated with a network with around 200ms RTT.
Here are the commands used: first a ping to confirm the RTT and then the actual file copy to both servers:
The performance chart below shows the two distinct events. First the quick SMB2 copy, then the longer SMB1 copy.
The x axis shows time and the y axis shows the amount of data per second on the network interface.
This was then repeated with a higher latency on the network (around 200ms round trip time). Here is the command line output:
This time the chart (below) shows an even more impressive advantage of SMB2 over SMB1.
You can clearly see how SMB2 uses request pipelining and SMB1, unable to do so, takes a lot longer to complete the task.
I have heard several comments on how this demo helped understand the protocol improvements.
Please keep in mind that, in order to use the new protocol, both sides have to support SMB2 (Windows Server 2008 and Windows Vista SP1 both support SMB2).