5. Configuring Driver Script options

To configure the Driver Script select Options under the Driver Script tree-view.

Figure 4.16. Driver Script Options

Driver Script Options

This displays the Driver Script Options dialog. The connection options are common to the Schema Build Dialog in addition to new Driver Options.

Figure 4.17. Driver Script Options

Driver Script Options

Table 4.7. Driver Script Options

TPC-C Driver ScriptFor all databases you have the option of selecting a Test Driver Script or a Timed Driver Script. The This choice will dynamically change the Driver Script that is loaded when the TPC-C Driver Script menu option is chosen. The Test Driver Script is intended for verifying and testing a configuration only by displaying virtual user output for a small number of virtual users. In particular both Windows and Linux graphical displays are single-threaded permitting only one Virtual User to write to the display at any one time. Therefore the performance of writing to the display will limit throughput. Consequently once a schema is verified to conduct measured tests you should select the Timed Driver Script Option.
Total Transactions per UserTotal transactions per user is reported as total_iterations within the EDITABLE OPTIONS section of the driver script. This value will set the number of transactions each virtual user will process before logging off. You can use this value to determine how long the virtual user will remain active for. The length of time for activity will depend upon the performance of the Database Server under test. A higher performing server will process the defined number of transactions more quickly than a lower performing one. It is important to draw the distinction between the total_iterations value and the Iterations value set in the Virtual User Options window. The Iterations value in the Virtual User Options window determines the number of times that a script will be run in its entirety. The total_iterations value is internal to the TPC-C driver script and determines the number of times the internal loop is iterated ie for {set it 0} {$it < $total_iterations} {incr it} { ... } In other words if total_iterations is set to 1000 then the executing user will log on once execute 1000 transactions and then log off. If on the other hand Iterations in the Virtual User Options window is set to 1000 and total_iterations in the script set to 1 then the executing user will log on execute one transaction and then log off 1000 times.You should ensure that the number of transactions is set to a suitably high vale to ensure that the virtual users do not complete their tests before the timed test is complete, doing so will mean the you will be timing idle virtual users and the results will be invalid.
Exit on ErrorExit on Error is shown as the parameter RAISEERROR in the Driver Script. RAISEERROR impacts the behaviour of an individual virtual user on detecting a database error. If set to TRUE on detecting an error the user will report the error into the HammerDB console and then terminate execution. If set to FALSE the virtual user will ignore the error and proceed with executing the next transaction. It is therefore important to be aware that if set to FALSE firstly if there has been a configuration error resulting in repeated errors then the workload might not be reported accurately and secondly you may not be aware of any occasional errors being reported as they are silently ignored.
Keying and Thinking TimeKeying and Thinking Time is shown as KEYANDTHINK in the Driver Script. A good introduction to the importance of keying and thinking time is to read the TPC-C specification. This parameter will have the biggest impact on the type of workload that your test will take. Keying and thinking time is an integral part of an official TPC-C test in order to simulate the effect of the workload being run by a real user who takes time to key in an actual order and think about the output. If KEYANDTHINK is set to TRUE each user will simulate this real user type workload. An official TPC-C benchmark implements 10 users per warehouse all simulating this real user experience and it should therefore be clear that the main impact of KEYANDTHINK being set to TRUE is that you will need a significant number of warehouses and users in order to generate a meaningful workload and hence an extensive testing infrastructure. The positive side is that when testing hundreds or thousands of virtual users you will be testing a workload scenario that will be closer to a real production environment. Whereas with KEYANDTHINK set to TRUE each user will execute maybe 2 or 3 transactions a minute you should not underestimate the radical difference that setting KEYANDTHINK to FALSE will have on your workload. Instead of 2 or 3 transactions each user will now execute tens of thousands of transactions a minute. Clearly KEYANDTHINK will have a big impact on the number of virtual users and warehouses you will need to configure to run an accurate workload, if this parameter is set to TRUE you will need at least hundreds or thousands of virtual users and warehouses, if FALSE then you will need to begin testing with 1 or 2 threads, building from here up to a maximum workload with the number of warehouses set to a level where the users are not contending for the same data. A common error is to set KEYANDTHINK to FALSE and then create hundreds of users for an initial test, this form of testing will only exhibit contention for data between users and nothing about the potential of the system. If you do not have an extensive testing infrastructure and a large number of warehouses configured set KEYANDTHINK to FALSE (whilst remembering that you are not simulating a real TPC-C type test) and beginning your testing with 1 virtual user building up the number of virtual users for each subsequent test in order to plot a transaction profile.
Checkpoint/Vacuum when completeWhere available the database will trigger a checkpoint after the workload is complete to write out the modified data from the in-memory cache to the disk. if the database is correctly configured this will prevent this activity being conducted during a test to result in higher performance.
Minutes of Rampup TimeThe Minutes of Ramup Time is shown as rampup in the Driver Script. The rampup time defines the time in minutes for the monitoring virtual user to wait for the virtual users running the workload to connect to the database and build up the transaction rate by caching data in the database buffer cache before taking the first timed value and timing the test. The rampup time should be sufficiently long enough for a workload to reach a steady transaction rate before the first timed value is taken.
Minutes for Test DurationThe Minutes for Test Duration is shown as duration in the Driver Script. The test duration defines the time of the test measured as the time the monitor thread waits after the first timed value before taking the second one to signal the test is complete and the active virtual users to complete their workload.
Use All WarehousesBy default each Virtual User selects a home warehouse at random from at the start of a test and remains with that home warehouse. Therefore for example if there are 100 warehouses created and 10 virtual users selected to run the Driver Script then most of the activity will take place on 10 warehouse only. This option means that the Virtual Users select a new warehouse for each transaction from an available list divided between all Virtual Users at the start of the test therefore ensuring greater I/O activity.
Time ProfileThis option should be selected in conjunction with having enabled output to the logfile. When selected client side time profiling will be conducted for the first active virtual user and output written to the logfile.
ModeThe mode value is taken from the operational mode setting set under the Mode Options menu tab under the Mode menu. If set to Local or Master then the monitor thread takes snapshots, if set to Slave no snapshots are taken. This is useful if multiple instances of HammerDB are running in Master and Slave mode to ensure that only one instance takes the snapshots.