Benchmarking

The benchmark command measures RouterOS API operations against a real router. It is intended for development and capacity planning, not for normal deployments.

Command

Build and run the benchmark:

go run ./cmd/benchmark

The config path is optional and defaults to config/test.yaml:

go run ./cmd/benchmark config/test.yaml

The benchmark reads the MikroTik section from the selected YAML file, connects to RouterOS, then runs API-level operations.

What it measures

• Single IPv4 and IPv6 address-list adds/removes.
• Address-list find and list calls.
• Firewall rule create, find, and remove calls.
• Sequential IPv4 batch add/list/find/remove timings.

The benchmark uses documentation-prefix test addresses such as 198.51.100.0/24 and 2001:db8::/32, but it still writes to the configured RouterOS address lists and firewall menus.

Caution

Run benchmarks on a lab router or during a maintenance window. The command creates temporary firewall rules and address-list entries and then removes them.

Example output

Connected to: lab-router

=== SINGLE OPERATION BENCHMARKS (RouterOS API) ===
  Add single IPv4                         35ms  OK
  Find IPv4 (1 entry)                     12ms  OK
  Remove IPv4 by .id                      18ms  OK

=== BATCH ADD BENCHMARKS (sequential via API) ===
  Add 100 IPv4 (sequential)                4s  (40ms/ip, failures=0)

Use the numbers to compare RouterOS versions, hardware models, TLS vs plaintext API, and network latency.

For real bouncer startup performance, prefer the functional CAPI tests because reconciliation uses script-based bulk adds and pool-based removals, not only sequential API calls.

Real-world results

These figures come from the functional CAPI test suite (tests/functional/) run against a MikroTik RB5009, not from the single-operation cmd/benchmark tool above. See Architecture: Connection pool and Script-based bulk add for the mechanisms behind these numbers.

Scenario	Result
Cache-first optimistic add (address not yet on the router)	~1–3 ms per operation
Check-first add (list entries before adding, avoided by cache)	~400 ms per IP
Script-based bulk add vs. sequential API calls	~97× faster for large batches
Full RB5009 bulk-add, ~28,700 CAPI-origin entries, pool_size: 10	~35–36 s total

The gap between cache-first (~1-3 ms) and check-first (~400 ms) is why the in-memory address cache described in Architecture exists: it lets the bouncer skip the RouterOS list-then-add round trip for addresses it already knows about.

For CAPI-scale deployments (tens of thousands of entries), also see CAPI Blocklists and Performance Tuning for pool_size sizing guidance.

Safety checklist

• Confirm the target is a lab router.
• Use dedicated test address lists when possible.
• Keep command_timeout high enough for slow devices.
• Check the router after interruption and remove any benchmark-* comments if a run is stopped midway.