Databases Reference
In-Depth Information
ZERO DELAYS MODE: 1
Stage 1. Starting up client...
Delay for each thread - 300 msec. Will sleep for 4 sec to start 10 database
connections
CLIENT_PID = 12962
Stage 2. Starting up driver...
Delay for each thread - 300 msec. Will sleep for 34 sec to start 100 terminal
threads
All threads has spawned successfuly.
Stage 3. Starting of the test. Duration of the test 300 sec
Stage 4. Processing of results...
Shutdown clients. Send TERM signal to 12962.
Response Time (s)
Transaction % Average : 90th % Total Rollbacks %
------------ ----- ----------------- ------ --------- -----
Delivery 3.53 2.224 : 3.059 1603 0 0.00
New Order 41.24 0.659 : 1.175 18742 172 0.92
Order Status 3.86 0.684 : 1.228 1756 0 0.00
Payment 39.23 0.644 : 1.161 17827 0 0.00
Stock Level 3.59 0.652 : 1.147 1630 0 0.00
3396.95 new-order transactions per minute (NOTPM)
5.5 minute duration
0 total unknown errors
31 second(s) ramping up
The most important result is this line near the end:
3396.95 new-order transactions per minute (NOTPM)
This shows how many transactions per minute the system can process; more is better.
(The term “new-order” is not a special term for a type of transaction; it simply means
the test simulated someone placing a new order on the imaginary ecommerce website.)
You can change a few parameters to create different benchmarks:
-c
The number of connections to the database. You can change this to emulate dif-
ferent levels of concurrency and see how the system scales.
-e
This enables zero-delay mode, which means there will be no delay between queries.
This stress-tests the database, but it can be unrealistic as real users need some
“think time” before generating new queries.
-t
The total duration of the benchmark. Choose this time carefully, or the results will
be meaningless. Too short a time for benchmarking an I/O-bound workload will
give incorrect results because the system will not have enough time to warm the
caches and start to work normally. On the other hand, if you want to benchmark
