You don’t need to create Response Probe’s script files wholly from scratch; you can modify the sample files in \ntreskit\perftool\probe\examples. Among these sample files are several sets of excellent baseline scripts that might suit many system designers’ testing needs:
- Diskmax.scr determines a disk drive’s maximum throughput by performing sequential, unbuffered reads of 64KB records from a 20MB file.
- Minread.scr measures how disk performance varies when reading one sector of the disk at a time; this sample file performs sequential, unbuffered 512-byte reads from a 20MB file.
- Sizeread.bat tests a disk configuration’s performance in reading records of increasing size. This file is a batch file rather than a process script file. Sizeread.bat runs a series of tests of unbuffered, sequential reads from a 20MB file in which the size of the record read increases from 2KB to 8KB, 64KB, 256KB, 1MB, and 4MB.
Configuring the Server
Before you launch Response Probe, configure the server hardware as you’d configure it for production work, then configure any secondary applications and utilities (e.g., antivirus utilities, system-monitoring software) that will run concurrently with the primary application. Run only those programs and services whose activity level won’t vary significantly over time. For example, a monitoring service such as NT’s SNMP Agent adds to the demand on a server, but that demand is constant—it doesn’t vary with the number of user connections or any other factor—so you can incorporate this service into the configuration. Conversely, you shouldn’t include Microsoft SQL Server in a test because that application’s impact varies.
Using Response Probe
Response Probe is installed on a server when you install the resource kit. Its installation has no parameters. The tool consists of the files in the \ntreskit\perftool\probe folder (including the examples subdirectory).
Running Response Probe is easy after you’ve defined the three script files. You run Response Probe from a command prompt. The syntax is
probe <ProcessFileName.scr>
<TrialTime>
<OutputFileName>
where ProcessFileName.scr is the name of the process script file that describes the threads you’re testing, TrialTime is the length of time (in seconds) that the test will run, and OutputFileName is an optional parameter that creates an output (.out) file to which Response Probe will save test results (the default output file name is ProcessFileName.out). You can’t direct the utility at another computer on the network; you must launch it from the system you want to test.
No Longer in the Dark
One of Response Probe’s most important uses is determining just how much more powerful a new server will be than the one it’s replacing. Manufacturers market server hardware with plenty of "performance figures," but how do increases in processor speed, disk-seek time, RAM capacity, processor bus size, and network-interface bandwidth really translate into overall performance? Many of these factors change with each new server model, so comparing servers based on the rated performance of their components becomes nearly impossible. Yet the most common question customers ask about a new server is, "How much faster is it going to run?"
I find Response Probe particularly valuable in answering this question because you can use it to create a true performance-based baseline. Run Response Probe on a 2-year-old application server that you’re using now, and you’ll have a relevant baseline for comparing candidates to replace it. Then, run Response Probe against the same software configuration on the newer servers, and you’ll have a result that correlates directly with the results you saw on the old server, clearly showing the performance difference between the two systems. Other tools, such as Microsoft Performance Monitor, provide information only about a server’s separate components. Response Probe gives a complete picture of the server’s overall performance.
End of Article
