Intel NAS Performance Toolkit. Creating Custom Workloads

Transcription

1 Creating Custom Workloads

2 1 Overview The Intel NAS Performance Toolkit (NASPT) uses a very simple XML input format to describe the workloads used in executing the tests. Users may specify their own workloads in addition to the set provided with the toolkit. This document provides the specification of the NASPT trace format and provides an example of mapping traces from one publicly available tracing tool to NASPT format. This document assumes the reader is familiar with the rudiments of XML and the basic workings of the Intel NAS Performance Toolkit as outlined in the NASPT User s Guide. 2

3 2 NASPT Trace Format All tests provided by the Intel NAS Performance Toolkit are described by XML trace files stored in the app_traces directory where the application is installed. By default, NASPT installs to C:\Program Files\Intel\NASPT. To add new traces, the user need only store their custom trace files in this app_traces directory. NASPT will then load all valid trace files at the next invocation. NASPT trace files should not contain ampersands or other characters that require special treatment in XML format. 2.1 XML Declaration All NASPT trace files should begin with the same three lines. The first line simply <?xml version="1.0"?> states that we re complying with the 1.0 version of the XML language specification. <?xml-stylesheet type="text/css" href="report.css"?> <TRACE> The second line refers to a simple style Test Header sheet, report.css, provided with NASPT that Transaction List allows users to view plain text listings in their web browser a little more easily </TRACE> should they desire to do so. Figure 1 - Basic NASPT File Format The rest of the file contains a bit of descriptive information in the header section and a list of transaction records all contained within the <TRACE> tag. 2.2 Header Format The first item within the <TRACE> tag is the file header; a short description of the test used by NASPT to tell users what workload the trace file models. The format of the trace header is: <HEADER> <TESTNAME>Name of test</testname> <DESCRIPTION>Description of test</description> <NOBUILD>true</NOBUILD> <TESTROOT>root directory</testroot> HEADER: The <HEADER> tag simply contains all of the entries </HEADER> that make up the NASPT test header. Figure 2 - NASPT Header Layout TESTNAME: The text entered here appears in the list of available tests when the user launches the NASPT Exerciser application. DESCRIPTION: The NASPT Exerciser uses this text field to provide a tooltip description when the user hovers their mouse pointer over the corresponding test name in the list of available tests. 3

4 NOBUILD: This tag is optional and has only one valid entry: the word true. If specified in the test header, this tag means that NASPT should treat the entire workload as write mostly. That is, none of the files accessed by this test are created during test preparation, although a root directory to contain them is created (see TESTROOT, below). During testing, NASPT creates new files and fills them with fresh writes as specified in the workload trace file. Any reads should only access data that has previously been written. After each test, NASPT deletes all of the files. This mechanism assists in modeling the behavior of workloads that will create a group of new files as part of the operation, as in a bulk copy from some other device to the test target. NASPT also allows the NOBUILD specification on individual files (see the NOBUILD tag for an individual record, below). TESTROOT: This tag is optional and is only used when the NOBUILD tag is also specified in the test header. A valid entry is the directory name where NASPT should direct transactions at test time. This is combined with the test target directory specified by the user to make a full path. For instance, if a trace header contains <TESTROOT>temp\testdir</TESTROOT> and the user has specified Z:\NASPT as their target directory, then files created by this trace will be built within the directory Z:\NASPT\temp\testdir. 2.3 Event Format Following the test header entry, the remainder of the trace file consists of trace events, individual records of transactions NASPT generates during the test. Each trace event record specifies exactly one file system transaction. The format of each record is as follows: <RECORD> <SEQUENCE_NUMBER>decimal number</sequence_number> <START_TIME>time in microseconds</start_time> <FINISH_TIME>time in microseconds</finish_time> <IRP_MAJOR>transaction type</irp_major> <ARG1>length in bytes (hex)</arg1> <ARG3>byte offset(hex)</arg3> <FILENAME>full path</filename> <NOBUILD>true</NOBUILD> </RECORD> Figure 3 - NASPT Record Layout 4

5 RECORD: Each individual entry is bounded by a <RECORD> tag. SEQUENCE_NUMBER: This is an ordinal number indicating the order in which the transactions occurred. Valid values are integers from 1 to 2,147,483,647. START_TIME: The time at which this transaction took place specified in microseconds. The first transaction in each trace should begin at time zero so that all other start times are then relative to the beginning of the test. This is a 64-bit unsigned integer field. FINISH_TIME: The time at which this transaction completed specified in microseconds. This is a 64-bit unsigned integer field. FINISH_TIME must never be less than START_TIME for the same transaction. IRP_MAJOR: This field has two valid entries, IRP_MJ_WRITE and IRP_MJ_READ, meaning that this transaction is either a write or a read. All other values are ignored. NASPT handles file opens and closes automatically at test time so it is not necessary to specify these in the trace files. ARG1: This field contains a 32-bit hexadecimal value specifying the number of bytes to transfer with this transaction. ARG3: This field contains a 64-bit hexadecimal value specifying the byte offset within the file at which to begin the transfer. FILENAME: This is the full path of the original file accessed with this transaction. The NASPT exerciser will replace the original drive letter with the test target specified by the user in the configuration dialog box. Note that NASPT works with drive letters (C:, X:, etc.) and not UNC paths (//server/share). NOBUILD: This field is optional. It s only valid value is the word true. If the very first transaction to a particular target file specifies this tag, NASPT will treat that file as a write-mostly file during testing. Behavior is the same as described in the global NOBUILD tag (under the test header description, above) but only affects an individual file. After the very first transaction to any particular file, any NOBUILD tags in subsequent transactions targeting that file are ignored. 5

6 3 Example Now that you ve seen the basic format of a NASPT trace file, let s look at an example of converting a captured workload trace to NASPT format. This example uses the publicly available Process Monitor application published by Microsoft Corporation. The tool is available for download from TBD. The workload in this example is simply opening a spreadsheet file. In the standard NASPT traces, the workloads are filtered so that only accesses to data files are included while accesses to executables, libraries, and system files are intentionally excluded. The method of implementing this filtering is dependent upon the workload capture mechanism employed. In this case, the user would need to be familiar with the Process Monitor application to effect the filtering. After configuring our workload capture tool to focus on just the transactions we wanted to capture, we obtained a trace of all the transactions issued while opening our spreadsheet file. We then saved that capture to file which Process Monitor conveniently packaged in XML format. The Process Monitor output file is of the following general format: <procmon> <processlist> List of software modules loaded on the system. </processlist> <eventlist> Collection of file system transactions that pass the user-specified filter </eventlist> </procmon> Figure 4 - Basic Format of a Process Monitor Output File For our purposes the second section, the event list, contains all the information we ll need to create our NASPT trace file. Figure is a representative entry from that list showing two read transactions directed toward our spreadsheet data file. Every event in Process Monitor s output matches this same format. It is from this information that we will construct our NASPT event records. 6

7 <event> <ProcessIndex>161</ProcessIndex> <Sequence>353962</Sequence> <Time_of_Day>1:27: PM</Time_of_Day> <Duration> </Duration> <Process_Name>SPREADSHEET_APP.EXE</Process_Name> <PID>2996</PID> <Operation>IRP_MJ_READ</Operation> <Result>SUCCESS</Result> <Detail>Offset: 0, Length: 512</Detail> <Path>J:\NASB\NASPTData\LATEST_DATA.xls</Path> </event> <event> <ProcessIndex>161</ProcessIndex> <Sequence>353968</Sequence> <Time_of_Day>1:27: PM</Time_of_Day> <Duration> </Duration> <Process_Name>SPREADSHEET_APP.EXE</Process_Name> <PID>2996</PID> <Operation>IRP_MJ_READ</Operation> <Result>SUCCESS</Result> <Detail>Offset: 1024, Length: 512</Detail> <Path>J:\NASB\NASPTData\LATEST_DATA.xls</Path> </event> Figure 5 Sample of Process Monitor's Output To translate these events into NASPT format we need to begin with the basic XML bookkeeping. Each NASPT file starts with the same XML declaration and opening <TRACE> tag: <?xml version="1.0"?> <?xml-stylesheet type="text/css" href="report.css"?> <TRACE> Figure 6 - Example XML Declaration The next item is the test header, which we ll fill out with our test name and some descriptive text: <HEADER> <TESTNAME>Test Example</TESTNAME> <DESCRIPTION>Just two simple transactions<description> </HEADER> Figure 7 - Example Test Header 7

8 After this, all that remains is to translate each of the events in Process Monitor s event list into NASPT records. First, recall that every NASPT transaction is bounded by the <RECORD> tag: SEQUENCE_NUMBER: Simply start at one and keep a running count as we go. START_TIME: Process Monitor reports a Time-of-Day start time in HH:MM:SS format. We need to translate this to microseconds for NASPT. Further, we ll use the start time for the first transaction as time zero and then express all the other times in the trace as offsets from this start time. In this case, we ll use 1:27: PM as time zero in our NASPT trace. FINISH_TIME: This value is calculated by adding Process Monitor s duration field to the START_TIME. Again, Process Monitor reports this field in HH:MM:SS so we ll need to translate to microseconds. For the first transaction, START_TIME is zero, so FINISH time is just Process Monitor s reported duration expressed in microseconds. In this case, seconds means our NASPT FINISH_TIME should be IRP_MAJOR: This field corresponds to Process Monitor s operation field. Transactions listing IRP_MJ_READ or IRP_MJ_WRITE in their operation field are the ones we want to translate to NASPT. There are numerous other I/O Request Packet (IRP) codes, but they are not used in generating NASPT workload traces. Conveniently, NASPT and Process Monitor use the same text for this particular field so no translation is necessary. ARG1: This field is the number of bytes to transfer. Process Monitor reports this value as a decimal number in the Length field of the <Detail> tag. Note that NASPT expects a hexadecimal number. Translating the first request s value of 512 to hexadecimal gives us 200 for NASPT s ARG1 value. ARG3: This is the base offset of this transaction within the file. Process Monitor reports this value as a decimal number in the Offset field of the <Detail> tag. Again, NASPT expects a hexadecimal number so we ll need to translate. For the first transaction, this value is zero. FILENAME: Process Monitor reports this value in the path field. NOBUILD: This example is reading an existing spreadsheet file. When we run the NASPT workload generated from this example, we ll want to be reading a file that s already on disk since that s what the original workload does. Therefore, we do not want to specify the NOBUILD tag. Here is the completed NASPT record of the first transaction translated from Process Monitor s output: 8 <RECORD> <SEQUENCE_NUMBER>1</SEQUENCE_NUMBER> <START_TIME>0</START_TIME> <FINISH_TIME>2469</FINISH_TIME> <IRP_MAJOR>IRP_MJ_READ</IRP_MAJOR> <ARG1>200</ARG1> <ARG3>0</ARG3> <FILENAME>J:\NASB\NASPTData\LATEST_DATA.xls</FILENAME> </RECORD> Figure 8 - Process Monitor event translated to NASPT format

9 <?xml version="1.0"?> <?xml-stylesheet type="text/css" href="report.css"?> <TRACE> <HEADER> <TESTNAME>Spreadsheet Test</TESTNAME> <DESCRIPTION>Just the first two transactions in reading a spreadsheet.</description> </HEADER> <RECORD> <SEQUENCE_NUMBER>1</SEQUENCE_NUMBER> <START_TIME>0</START_TIME> <FINISH_TIME>2469</FINISH_TIME> <IRP_MAJOR>IRP_MJ_READ</IRP_MAJOR> <ARG1>200</ARG1> <ARG3>0</ARG3> <FILENAME>J:\NASB\NASPTData\LATEST_DATA.xls</FILENAME> </RECORD> <RECORD> <SEQUENCE_NUMBER>2</SEQUENCE_NUMBER> <START_TIME>16258</START_TIME> <FINISH_TIME>18786</FINISH_TIME> <IRP_MAJOR>IRP_MJ_READ</IRP_MAJOR> <ARG1>200</ARG1> <ARG3>400</ARG3> <FILENAME>J:\NASB\NASPTData\LATEST_DATA.xls</FILENAME> </RECORD> </TRACE> Figure 9 - Completed NASPT trace file Above is the complete NASPT trace file constructed from these two Process Monitor transactions. We can now place our completed file (with the.xml extension) in our NASPT traces directory. By default, NASPT stores its traces in C:\Program Files\Intel\NASPT\app_traces. The next time we launch the NASPT Exerciser, we should see our new test in the list of available workloads on the right-hand side of the GUI: Figure 10 - NASPT Exerciser with custom test 9

10 4 Conclusion Creating custom workloads for the Intel NAS Performance Toolkit is a simple and straightforward process that allows users to design exactly those workloads of most interest to them. All you need is some tracing mechanism to capture file system transactions as you execute your desired workload. (Alternatively, one could algorithmically generate an entirely synthetic workload.) The information needed for each transaction is: Start and finish times, expressed in milliseconds Base offset and length, in bytes Filename, including absolute path information Transaction type, read or write With this information and your favored scripting language, you should be well on your way to creating your own custom NASPT workloads. This information is provided as-is in the hopes that it will be useful to the NASPT user community and add to the utility of the Intel NAS Performance Toolkit. Questions and comments may be submitted to NASPT_Support@intel.com. 10

11 The Intel NAS Performance Toolkit ("Software") is furnished under license and may only be used or copied in accordance with the terms of that license. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. The Software is subject to change without notice, and should not be construed as a commitment by Intel Corporation to market, license, sell or support any product or technology. Unless otherwise provided for in the license under which this Software is provided, the Software is provided AS IS, with no warranties of any kind, express or implied. Except as expressly permitted by the Software license, neither Intel Corporation nor its suppliers assumes any responsibility or liability for any errors or inaccuracies that may appear herein. Except as expressly permitted by the Software license, no part of the Software may be reproduced, stored in a retrieval system, transmitted in any form, or distributed by any means without the express written consent of Intel Corporation. Copyright 2008, Intel Corporation