You describe a workload to Response Probe by submitting script files and a simulated workload file. The name of the workload file is included in the script files.
Script files are small, formatted text files you create with a text editor such as Notepad. The script files describe a simulated workload to Response Probe in terms of processes and their threads. There are three types of script files, and at least one of each type is required for each Response Probe run. Response Probe identifies the file type by its three-character file extension. You can assign any name to the files; simply add the correct file extension:
Tip
You needn't create the files from scratch. Use the sample files on the Windows NT Resource Kit 4.0 CD in the Probe subdirectory as a starting point.
The files are closely related. Each process definition in the Process file includes the name of the file where threads for that process are defined. The definition of each thread includes the name of the file where the threads are described.
In the Process script file (*.scr), you create the processes that Response Probe runs. The file consists of one or more process lines, each of which creates, names, and specifies the attributes of one process.
Note
Response Probe 2.0 and earlier required that you create a simulated code page file and enter its name in the Process Script file. Response Probe versions 2.1 and later include an internal 1000-function codepage file. They do not require, and will not accept, a CodePageFileName parameter.
By default, Response Probe tests run in a process called Probeprc.exe. You can change the process name to make it easier to distinguish among Response Probe tests in Performance Monitor. Although Performance Monitor 3.51 and later let you monitor multiple processes with the same name, changing the name makes later analysis easier.
To change the process name, copy Probeprc.exe to a file with a different name. Then, enter that name in the optional ProcessName field.
The REPEAT parameter creates separate processes with the same process name. In Performance Monitor, the Process object Instances box will show several instances of the same named process.
The format of each process line is
[REPEAT n] PROCESS ThreadDfFilename.scp DataSize [ProcessName
[PriorityClass]] [# Comments]Item | Description |
REPEAT n | Creates n instances of the process. Each repetition runs the same test with the same process name. This field is optional. The default is 1. |
PROCESS | Required word that identifies the process statement. |
ThreadDfFilename. scp | Name of the file that defines the threads for the process. When processes are repeated, all repetitions share the same Thread Definition file. |
DataSize | Number of pages of virtual memory allocated to simulate data pages. For repeated processes, this number of pages will be allocated for each repetition. The minimum is 0. 10 is a commonly used value. |
ProcessName | The name the process in which the test runs. You can change the process name to distinguish among Response Probe tests when analyzing them. To change the process name, copy Probeprc.exe to a file with the new process name. This field is optional, but is required if you choose a priority class. |
PriorityClass | The base priority class of the process. Valid entries are I (idle = 4), N (normal = 8), H (high = 13), and R (realtime = 24). Enter only the first letter of the priority type. N is the default. This field is optional, but if you choose a priority class, you must also have a process name other than Probeprc.exe |
Comments | Comments can be included anywhere in the Process script file. Begin each line of comments with a # character. |
For example, the following line runs one Response Probe test with a 500-page paging file in the PROBE06.EXE process at high priority:
PROCESS TestDisks.scp 500 Probe06.exe HThe following line runs three identical processes, each having the threads defined in A971012.scp. The processes share a 300-page paging file. All of the processes are called Probeprc.exe.
REPEAT 3 PROCESS A971012.scp 300
In the Thread Definition file (*.scp), you create the threads that run in the Response Probe processes. This file consists of one or more thread definitions. Each definition creates one thread and associates it with a thread description file.
The format of a thread definition is:
[REPEAT n] THREAD ThreadDescFile.SCT [ThreadPriorityAdjustment]Item | Description |
Repeat n | Creates n instances of the thread. Each instance is treated as a separate, though identical, thread. This field is optional. The default is 1. |
THREAD | Required word that identifies the thread statement. |
ThreadDescFile. SCT | Name of the file where the characteristics of the thread are described. If the thread is repeated, all repetitions will share the same Thread Description file. |
ThreadPriority Adjustment | The amount by which the priority of the thread differs from the priority of the process. This field is optional. N is the default. Options are: (T)TimeCritical = +15, (H)Highest = +2, (A)AboveNormal = +1, (N)Normal = 0, (B)BelowNormal = -1, (L)Lowest = -2, and (I)Idle = -15. Enter only the first letter of the priority adjustment. You don't have to name threads to adjust their priority. |
For example:
THREAD ThreadDesc.sct– Or –
REPEAT 4 THREAD FastThread.sct IYou can also set a priority adjustment for the thread based upon the priority of the process. The actual priority of the thread will be the base priority of the process plus or minus the adjustment.
For example, if you set the priority of the process to Normal (8), and the thread adjustment to L (-2), the thread would run at priority 6.
In the Thread Description file (*.sct), you set values for the parameters that describe each thread. The parameters may be listed in any order. The sample thread description files on the Windows NT Resource Kit 4.0 CD are a good starting point for creating your own thread description files.
Note
In Response Probe versions 3.51 and later, the CODEPAGE parameter has been replaced by the FUNCTION parameter.
Thread Description files are arranged in a table. Each line is in the following format:
PARAMETER_NAME Mean StandardDeviation Comments
The following table describes the parameters. Optional parameters are shown in brackets [].
Parameter Name | Description | Valid Values for Mean | Values Often Used | |||||||||||
THINKTIME | The mean and standard deviation of the idle time between processing, in milliseconds. | 0 to trial time. | Mean = 0; or Mean = 100 | |||||||||||
CYCLEREADS | The number of times FILEACTION and CPUTIME are executed between think times. Enter the mean and standard deviation. | Minimum is 1. | Mean = 0 | |||||||||||
CPUTIME | The time spent in compute state. Enter the mean and standard deviation in milliseconds. | 0 to trial time. | Mean = 0; or Mean = 100 | |||||||||||
DATAPAGE | The position of the page to be written to in Response Probe's simulated data page file. Enter the mean and standard deviation of the page number. | 0 to the data size specified in the Process script file (*.scr). | Use the midpoint as a mean and 1/6 as the standard deviation. In a 10-page file, use Mean=5, Sdev = 2. | |||||||||||
FUNCTION | The position of the function to be read from Response Probe's 1000-function internal code page file. Enter the mean and standard deviation of the function to be read. | 1- 1000 | Mean = 500 | |||||||||||
FILEACCESS | The name of the workload file to be used in the test. This file can be created manually or by using the CREATFIL utility. | |||||||||||||
FILESEEK | The position of the record to be accessed in a file. Enter the mean and standard deviation of the record number. This parameter is required for random file access and is ignored for sequential file access. | 1 - #records in file. To find #records, filesize (bytes) / recordsize (bytes) | Use the midpoint as a mean and 1/6 as the standard deviation. In a 10-page file, use Mean=5, Sdev = 2. | |||||||||||
[RECORDSIZE] | Size of each read from or write to the FILEACCESS workload file, in bytes. This parameter is optional. The default is 4096 bytes. If you change RECORDSIZE, the midpoint of the file will change, so remember to change FILESEEK to match it. | On buffered reads, 1 - filesize. On unbuffered reads, the minimum is one sector of the disk. Use the Windows NT Diagnostics Drive page to find the sector size for your disk. | Filesize/ Recordsize = #records. In a 20 MB file with 4096K reads, #records = 5000. Use: | |||||||||||
[FILEATTRIBUTE] | Enter RANDOM or SEQUENTIAL. This parameter is optional. RANDOM is the default. In random access, record numbers are chosen based on a normal distribution. For sequential mode, the record number from the last FILE ACCESS phase is used as a starting point. When the file system opens the file, it is told that the file is accessed sequentially. This maximizes read-ahead by the cache manager. | |||||||||||||
[FILEACCESSMODE] | Specifies how files are accessed. This parameter is optional. BUFFER is the default. Valid values are BUFFER (use file system cache), UNBUFFER (no cache) or MAPPED (array in memory). If UNBUFFER is selected, RECORDSIZE must be a multiple of the disk sector size. | See Chapter 6, "Detecting Disk Bottlenecks," for more information. | ||||||||||||
[FILEACTION] | Specifies the pattern of reads and writes by using the letters R and W. For example, RWRRWWRRRWWW. This parameter is optional. The default is R (one read). | |||||||||||||
Tip
Type comments about each parameter after its specification. Any text on the parameter line after the standard deviation field is ignored. You might include a note on your rationale for that choice, list the units of measurement of the parameter, the date of the last change, your initials, or additional descriptions.
Another Tip
Code pages are read and data pages are written once in each processor loop. To determine how many loops your processor generates per second, check the Relative Processor Speed field in the Response Probe output file, described later in this chapter.
Yet Another Tip
In buffer mode, Response Probe simulates fast reads (reads that bypass the I/O Manager file system and go directly to the Cache Manager). When charting Response Probe tests with Performance Monitor, add the Sync Fast Reads/sec or Async Fast Reads/sec counters to see this activity.
Here are some sample thread description files. There are more on the Windows NT Resource Kit 4.0 CD, and many have text files explaining how to use them.
This sample file tells Response Probe to do nothing and produces almost no response, because Response Probe calculates its own overhead and subtracts it from each cycle.
| | |
| | |
| | |
| | |
| | |
| | |
| | |
The following example might be used to test disk performance. Response Probe is configured to read the same 4096-byte record in the ACCESS.DAT file 100 times without using the file system cache. Because the standard deviation for CYCLEREADS and FILESEEK is 0, the same record is read exactly 100 times in each cycle. The FILEACCESSMODE is set to UNBUFFER so the system bypasses the cache and goes directly to disk. (Remember, when using UNBUFFER, the RECORDSIZE must be a multiple of the disk sector size.)
The order of the parameters are changed and optional fields are included to make the test record more complete and easy to understand.
| | | ||||
| | |||||
| | |||||
| | |||||
| | |||||
| | |||||
| | | ||||
| | | ||||
| | | ||||
| | | ||||
| | | ||||
The following example simulates an application reading very small files directly from a 20 MB file on disk without using the file system cache. This sample test is on the Windows NT Resource Kit 4.0 CD in the Probe subdirectory. There are three variations, each reading slightly larger records. The files are called 512.sc*.
During this test, for each cycle, Response Probe is idle for an average of 1000 milliseconds, then does an average of 100 reads and writes randomly throughout the 40000-record (512-byte records in a 20 MB file) file. Then it computes for an average of 10 seconds, during which it write randomly throughout the 10-page datapage file and reads randomly throughout the 1000-function codepage file.
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | ||
| | ||
| | ||
| | ||
| | ||
The Process Script file includes the name of the workload file, a file that simulates data records that are read from and/or written to during the process. The content of this file is irrelevant, but its size is crucial. Performance often varies directly with the size of the file.
You enter the name of the workload file in the FILEACCESS parameter of the Thread Description file (.sct).
You can use real workload files, simulate them manually or use the Createfile utility, Creatfil.exe, to create them for you.
The Windows NT Resource Kit 4.0 CD includes CreateFile, a utility to create zero-filled files of a size you specify.
The CreateFile utility is installed when you do a typical installation or do a custom installation of Performance Tools. It is in \\ RESKIT\PerfTool\Probe\creatfil.exe. It must be run from the Command Prompt Window; it cannot be run from the Run command on the Start button.
At the command prompt, type:
creatfil filename [filesize]
where filename is the name of the file it will create and filesize is the size of the file it will create, in units of 1024K bytes. The filesize is optional. The default is 1024K bytes.
For example, to create a 100K file called workfile.dat, type:
c:\ RESKIT\PERFTOOL\PROBE> creatfil workfile.dat 100Creatfil produces a 1,048,576-byte file of zeros called workfile.dat.