Chapter 32

Load Tester

Model a business workflow as a tree of steps, then run it across many concurrent, real database sessions. It surfaces the lock contention and slow SQL that single-session testing never shows.

#32.1Layout

Left — saved load tests for this connection, each with its last-updated time.
Right — the current test: a header with actions, then three tabs — Definition, Options, Results.

#32.2Header actions

Button	Action
Load File	Opens a `.loadtest.json` file. Warns if you have unsaved changes or a run in progress.
Save ▾	Save to Load Tests (into DBCraft’s local store) or Save to File… (a portable `.loadtest.json`, for version control or sharing between machines).
Run / Stop	Starts or stops the workload.

An unsaved badge appears next to the test name when there are pending edits.

#32.3Building the workflow (Definition tab)

The workflow is a tree. Three node types:

Node	Icon	Purpose
Step	▶	Executes SQL. Can be repeated n times and can pause after each execution.
Loop	⟳	Repeats its child nodes n times.
Pause	⏱	Think time — waits a fixed number of milliseconds.

The toolbar down the right side of the tree:

Button	Action
+	Add a step at the top level.
↳	Add a step as a child of the selected node.
⟳	Add a loop.
⏱	Add a pause.
↑ / ↓	Move the selected node among its siblings.
🗑	Delete the selected node and its children.

Selecting a node opens its editor below, with up to three tabs:

Properties — Name; plus Repeat count (steps), Loop count (loops), and Delay after each execution (ms) / Pause (ms).

SQL (steps only) — the statement or anonymous PL/SQL block. Bind variables use :name. Two powerful behaviours:

RETURNING … INTO :name captures values for use by later steps.
A SELECT’s first-row columns become variables for later steps, under their column names.

Variables (steps only) — define random variables, each with a name and a min/max range. A new value is drawn on every execution, so each session hits different rows instead of all of them contending on one. Captured values from earlier steps are available automatically and need no declaration here.

New tests start with a two-node sample workflow (a probe SELECT and a 250 ms think time) so there is always something runnable.

#32.4Options tab

Concurrency

Option	Meaning	Default
Concurrent sessions	Threads; each opens its own real database session. Maximum 200.	5
Iterations per session	Complete workflow passes per session.	10
Ramp-up between sessions (ms)	Staggers session starts instead of a thundering herd.	0

Transactions

Mode	Behaviour
Autocommit	Each statement commits.
Commit each iteration	One commit per workflow pass.
Rollback each iteration	Rolls back each pass — keeps the schema clean while still exercising locks, undo and redo.

Scripts

Initialization script — runs once before the test starts.
Finalization script — runs once after all sessions finish.

#32.5Running and reading results

Press Run; the view switches to Results and polls live every second.

Stat tiles: Elapsed · Sessions (active/total) · Executions · Errors · Status. Errors turn red when non-zero. A fatal error appears in a red banner.

Step metrics table: per step — Executions · Errors · Avg ms · Min ms · Max ms · Last error. Rows with errors are tinted red.

Charts:

Average execution time by step — a horizontal bar chart; bars for steps that produced errors are red.
Execution time over the run — a line chart of individual execution durations against elapsed seconds, which is where you see contention building.

Run log — a live streaming log, capped at the most recent 2000 lines.

Export CSV (available once a run has finished) downloads the full result data.

A load test does real work against a real database. Point it at a test system. If you must run it elsewhere, use Rollback each iteration and a low session count, and tell your DBA first.