This directory supports two kinds of measurement:

• server/API acceptance via k6
• queue drain time via the queue benchmark tool

Use both. A fast summary.json only tells you the API accepted work quickly. The queue summary tells you how long workers took to finish it.

From the repo root:

python3 tests/loadtest/tools/dashboard.py

That starts the dashboard server, opens your browser, and scans tests/loadtest/ for:

• summary*.json
• queue-summary*.json
• run*.ndjson

If you do not want it to open a browser automatically:

python3 tests/loadtest/tools/dashboard.py --no-open

Open:

http://127.0.0.1:8765/dashboard/

These are the main flow tests to compare:

• hot-to-cold-no-shard
  • one hot source sends to many cold destinations
• cold-to-hot-no-shard
  • many cold sources send to one hot destination
• hot-to-cold-shard
  • same as above, but the hot source is split into source buckets first
• cold-to-hot-shard
  • same as above, but the hot destination is split into destination buckets first

tests/loadtest/script.js now has explicit scenarios for:

• hot_source
• hot_destination

And supports optional sharding with:

• SOURCE_BUCKETS
• DESTINATION_BUCKETS

Use the helper script from the repo root:

bash tests/loadtest/run_case.sh hot-to-cold-no-shard

That will:

1. start the queue benchmark
2. run the k6 load test
3. wait for the queue benchmark to finish
4. write three files into tests/loadtest/

The output files are:

• summary-<case>.json
• run-<case>.ndjson
• queue-summary-<case>.json

Examples:

bash tests/loadtest/run_case.sh hot-to-cold-no-shard
bash tests/loadtest/run_case.sh cold-to-hot-no-shard
bash tests/loadtest/run_case.sh hot-to-cold-shard
bash tests/loadtest/run_case.sh cold-to-hot-shard

If the hot queue is enabled and you want the queue benchmark to include it:

bash tests/loadtest/run_case.sh hot-to-cold-no-shard hot

That makes the queue benchmark watch both:

• new:transaction_*
• hot_*

If you want to run the tools manually instead of using run_case.sh, use two terminals.

Terminal 1, start the queue benchmark:

go run ./tests/loadtest/tools/queue_benchmark.go \
  -redis-dsn "$BLNK_REDIS_DNS" \
  -queue-prefixes "new:transaction_,hot_" \
  -wait \
  -out tests/loadtest/queue-summary.json

Terminal 2, run k6:

k6 run \
  --out json=tests/loadtest/run.ndjson \
  -e SUMMARY_OUT=tests/loadtest/summary.json \
  -e URL='http://localhost:5001/transactions' \
  -e SCENARIO='hot_source' \
  -e DURATION='30s' \
  -e RATE='300' \
  -e VUS='200' \
  -e MAX_VUS='800' \
  -e SOURCE_BUCKETS='1' \
  tests/loadtest/script.js

For cold-to-hot:

k6 run \
  --out json=tests/loadtest/run.ndjson \
  -e SUMMARY_OUT=tests/loadtest/summary.json \
  -e URL='http://localhost:5001/transactions' \
  -e SCENARIO='hot_destination' \
  -e DURATION='30s' \
  -e RATE='300' \
  -e VUS='200' \
  -e MAX_VUS='800' \
  -e DESTINATION_BUCKETS='1' \
  tests/loadtest/script.js

To rerun the same test with sharding:

• for hot_source, raise SOURCE_BUCKETS
• for hot_destination, raise DESTINATION_BUCKETS

Example:

k6 run \
  --out json=tests/loadtest/run.ndjson \
  -e SUMMARY_OUT=tests/loadtest/summary.json \
  -e URL='http://localhost:5001/transactions' \
  -e SCENARIO='hot_source' \
  -e DURATION='30s' \
  -e RATE='300' \
  -e VUS='200' \
  -e MAX_VUS='800' \
  -e SOURCE_BUCKETS='8' \
  tests/loadtest/script.js

Use this sequence and keep all generated files:

1. run hot-to-cold-no-shard
2. run cold-to-hot-no-shard
3. review queue drain time and keep the reports
4. shard and rerun the same two cases
5. compare the new reports against the no-shard runs
6. if you want to test queue optimizations on top, turn on worker concurrency, coalescing, or hot lane and rerun the sharded cases

For each case, inspect both:

• server summary
  • summary-<case>.json
• queue summary
  • queue-summary-<case>.json

Read them like this:

• summary
  • how fast the API accepted the transactions
• queue-summary
  • how fast the workers drained the queued work

The most useful comparison fields are:

• throughput
• p95 latency
• duration
• total processed

If the server numbers are good but queue duration is still high, the bottleneck is in worker drain, not API acceptance.