As you probably know, DTM DB Stress is a tool that emulates client activities to test the server sides of applications or even database servers.
There are two basic notions you have to understand to use this tool. A task is a class of client activity with certain behavior and a set of options. In other words, a task is a class of virtual users of your database or server application.
The second notion is a thread. A thread is an instance of the activity specified by task properties. It means each task consists of one or more threads.
|
For example, if you have a class of activities called "accountant" and want to emulate five users with this behavior, you should create one task and five threads. The professional version of the stress tool allows you to run an unlimited number of tasks and threads concurrently whereas the standard version is limited to 64 threads only. However, you have some limitations imposed by your operating system and hardware in reality. The stress tool can execute all specified tasks concurrently, sequentially or by groups. We should describe the last option in details. Suppose you have two data loading tasks, five data processing tasks and one analyzing task. The tasks grouping feature allows you to emulate the mentioned activities sequentially but concurrently in each group. It means any processing task will be executed after the last loading task is complete. |
|
Test Job Customization
The property of the main task is an SQL statement or a set of statements that describe client activity. There are two types of statements: static and dynamic. The dynamic statement has one or more parameters that will be calculated during thread execution. This option makes the task more flexible. The standard version of the tool has only one source of the parameter value - an external text file. The professional one offers one more option - a built-in random data generator.
As an example, we will take a client who retrieves orders from
the server to the client for a random range of dates. Task's SQL statement is
"SELECT * from ORDERS where OrderDate between ?1 and ?2"
"?1" and "?2" are parameters. Next, we prepare text file like following:
"12/12/2008" "12/02/2009"
"01/01/2008" "12/01/2008"
"01/01/2008" "12/01/2008"
For the first run, the stress tool converts statement to
SELECT * from ORDERS where OrderDate between "12/12/2008" and "12/02/2009"
For the second to
SELECT * from ORDERS where OrderDate between "01/01/2008" and "12/01/2008", etc.
Please note that the standard edition supports up to 10 parameters whereas the professional edition supports up to 99 parameters.
We should also mention the prologue and epilogue scripts as the options of the task. These options allow you to specify the start and end activities of the virtual user. We mean such activities as setting up the environment or updating statistics.
Client Activity Emulation
The task has a few timeout options that make the virtual user's behavior more realistic. They are
- the delay before the first execution
- the delay between thread executions
- the delay between statement executions for tasks with several SQL statements
Some tasks create one or more result sets. You can emulate real network loading by sending these data sets to the client or you can discard the produced data rows.
|
To emulate the activity of a real client, the program offers six methods to stop task execution. The simplest one of them is manual stop by the corresponding button or menu item. The second method involves individual task properties. In this case, you should specify how many times the thread of each task must be executed. Also, you may specify the number of seconds the whole project should be executed for. The last set of the methods includes specifying the number of executions for each task or all tasks. |
|