threadexecution

NAME
SYNTAX
DESCRIPTION
USAGE
EXAMPLE
BUGS
COPYRIGHT
SEE ALSO

NAME

threadexecution − RWP*Load Simulator start and control threads

SYNTAX

threadexecution ::=
run
  thread ; { thread ; }
end [ run ]


thread ::=
threads expression [ atclause ]
  statementlist
end [ threads  ]

DESCRIPTION

The run keyword initiating thread execution is the primary means in the RWP*Load Simulator to simulate actual workload, which it does by starting threads and waiting for these to complete. Threads are grouped, and all threads in each group execute the same.

USAGE

Each group of threads consists of a specified number of threads that execute the same list of statements; the number of threads (which must be zero or larger) is provided as the expression after the threads keyword. Similarly to the execute statement, you can optionally provide an at clause to specify a database that the threads will use while executing the list of statements.

The threads will be started using the threading interface of Oracle Call Interface and the threads will start executing immediately and will finish when the last statement in the list finishes. To have threads start actual work at a known time, you must use the control loop with some start time. You must similarly use a control loop if you want threads to run for some period of time using the stop option in the control loop.

Variables except those with the threads sum attribute and files open for reading will initially have their values from the main program. At thread start threads sum variables will have the value zero and the value will be added to the value in main when threads complete. Files open for reading will be closed in threads.

It is common that different threads should execute different workloads, which can be achieved in two different ways:

If the work to be performed has a different nature, say some threads execute business logic while others execute dba work, you start these as different groups of threads i.e. using multiple threads ... end keywords. You would often also use different at clauses for these.

If you want your threads to emulate different types of business logic that each is implemented in some procedure, use a single thread group - possibly with many threads - that all execute some random procedure.

EXAMPLE

The following example shows a total of 11 threads being started.

The first ten will start at the common start time and 10 times per second (i.e. with a random arrival rate of 0.1s between each) randomly execute one the three types of business logic. Assuming each of the three business logic procedures include some sql processing, and assuming the database named mydb uses a session pool, a database session will be acquired and released at the begin and end of each procedure call.

The last thread will call the procedure syswork() every 10s.

All threads will run for 300 seconds.

procedure abc() ... end;
procedure def() ... end;
procedure xyz() ... end;

random procedure array doit (abc 5, def 70, xyz 25);

procedure syswork() ... end;


run
  threads 10 at mydb
    for queue every erlang2(1/10) stop 300 loop
      doit();
    end;
  end;
  threads 1 at systemdb
    for start 10 every 10 stop 300 loop
      syswork();
    end loop;
  end threads;
end;

BUGS

It could very well be considered a bug, that a thread execution is not a statement and therefore cannot be done inside a procedure or inside any compound statement; it is only available as part of your main code similar to complex declarations. Fixing this will, however, be very complex and the restriction is unlikely to be lifted.