Microsoft has a history of developing tools for internal use and then later releasing them as commercial products to the public. The File Server Capacity Tool is right in line with that tradition.
Whenever a new server is put into service, it ought to be standard procedure to perform capacity and load testing on it, no matter what its function. Testing a file server's load-handling capacity makes sense no matter what the scenario.
The Windows Server Performance Team created the File Server Capacity Tool (FSCT) as a way to assess the performance of the different builds of Windows Server—for instance, to see if a given build has regressed in its performance—but it’s also a valuable addition to any administrator’s toolkit for assessing system loads.
FSCT works by creating traffic to and from a server using the Server Message Block (SMB) protocol, which is what Microsoft OSes use to control how files are sent between machines using a network protocol (typically TCP). The program uses native Win32 APIs to simulate this network behavior, and can also simulate behaviors such as multiple user requests from a single client. The tool is small—only 700K or so—and comes with both instructions and a whitepaper that explains the technology used. You should know there are 32- and 64-bit editions of the tool, so be sure to use the appropriate one for each machine running FSCT.
FSCT requires that admins use at least three separate machines: the server, the client and the controller. The first two should be obvious: the server is the machine used for load-testing and the client is a machine used to simulate user activity on the server. The controller coordinates the testing process between server and client(s), harvests statistics from both and generates reports on the results.
If it isn't already obvious, admins can have more than one client in the setup. There are no limits to the number of clients that can connect, but the machine testing as a server may have inbound connection limits. For example, Windows 7 Ultimate has an inbound SMB connection limit of 20 users. The number of connections on any edition of Windows can be found by typing NET CONFIG SERVER from an admin-level prompt.
An Active Directory domain controller can be used as part of the test, but it’s also possible to run FSCT in a conventional peer-to-peer workgroup environment. It’s also possible to use a non-Windows server that supports SMB as a test target, provided the clients and controller computer are Windows-based. Note that the server should not be used as a production machine during testing, as a way to limit the number of variables present.
When running FSCT on a given client/server configuration, admins use a "workload," an XML file which describes a series of user actions called "scenarios." Scenarios—file operations, things like renaming or deleting a file—are executed via .DLLs supplied with the FSCT. Since the workloads are just XML files, it’s a pretty straightforward process to edit them or create custom workloads. It is also possible to specify files to be used with the workload such as a large file to test the speed of copying that file to or from the server. By default, only one workload is included with FSCT: “HomeFolders,” which simulates the behavior of a user’s own home folder with about 100 megabytes of data in it.
FSCT isn’t exclusively for server editions of Windows. It can also be used with desktop systems as the target, as a way to gauge how well a given desktop can satisfy SMB requests over a given network connection or with its current complement of hardware (hard disk, memory, etc.).
In addition to the documentation supplied with the program, there’s a TechNet forum where users can post feedback or get answers to problems with FSCT. Note that many common errors and questions are covered in the FSCT’s own documentation as appendices.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Serdar Yegulalp has been writing about personal computing and IT for more than 15 years for a variety of publications, including (among others) Windows Magazine, InformationWeek and the TechTarget family of sites.
This was first published in June 2011