JobMaster + RavenDB + NATS
JobMaster lets you run the master connection and every agent connection on different providers entirely -- for example, RavenDB as the master database with NATS as the agent-side transport instead of RavenDB itself. This page benchmarks that split-topology config on its own, separately from the single-server comparison, since it isn't a fair apples-to-apples comparison against configs where the same database serves both roles.
Note on hardware: this run still executes all containers (RavenDB, NATS, and all 20 workers) on one Docker host/EC2 instance -- the benchmark harness doesn't spread containers across separate physical machines. What's being measured here is the software-level topology split (master DB and agent transport as two independently-resourced, independently-scaling roles), not physical server separation.
Average of 3 repeated runs. See Benchmark Methodology for the shared test setup (burst-mode shape, repetition rule).
- Total burst jobs: 50,000
- Requests: 60 x 833 jobs each (all fired in parallel)
- Workers: 20
- DB (RavenDB master) resources: 3 CPU / 6 GB
- NATS (agent transport) resources: 4 CPU / 6 GB
- Worker resources: 2 CPU / 4 GB
- EC2 instance:
m6id.16xlarge(64 vCPU / 256 GB) - Reps averaged: 3
Throughput & correctness
-
Scheduling throughput: 23888 jobs/sec (avg of 3 reps) -- NATS as the agent transport removes RavenDB entirely from the scheduling hot path, which shows here: several times faster to accept a burst than any single-server config on the main comparison page.
-
Execution throughput: 327.1 jobs/sec (avg of 3 reps, measured over the actual span from run start to the last real completion)
-
Lost / not completed / not scheduled: 0 (every rep)
-
Duplicated: 0 (every rep)
Schedule-call latency
Latency of a single /schedule-now call, each scheduling a batch of ~833 jobs in one request. All 60
requests were sent at the same time across all workers, so these numbers reflect how long the API
took to accept and durably persist a batch under full concurrent load, not how long any one job
waited. Averages below are across all 3 reps' own mean/p50/p90/p99/max.
| mean (ms) | p50 (ms) | p90 (ms) | p99 (ms) | max (ms) | samples | |
|---|---|---|---|---|---|---|
| schedule-now call | 1469 | 1462 | 1674 | 2221 | 2221 | 60 |
Execution latency
How long each job sat waiting, on average, from the moment it was accepted by the schedule call until it was actually picked up and executed by a worker: the queueing/dispatch delay, separate from how long the schedule call itself took to return.
| mean (ms) | p50 (ms) | p90 (ms) | p99 (ms) | max (ms) | samples | |
|---|---|---|---|---|---|---|
| Immediate | 63969 | 63905 | 111859 | 124009 | 153164 | 50000 |
Container resource usage
Averages/maxes across all reps. Workers averaged across all 20 containers per rep, then across reps.
| Container | limit (CPU/mem) | avg CPU% | max CPU% | avg mem (MB) | max mem (MB) |
|---|---|---|---|---|---|
| db (RavenDB master) | 3 CPU / 6 GB | 125.4 | 190.5 | 1818.7 | 2098.9 |
| nats (agent transport) | 4 CPU / 6 GB | 54.2 | 90.9 | 309.2 | 330.0 |
| workers (avg of 20) | 2 CPU / 4 GB | 16.7 | 19.9 | 506.6 | 514.2 |
Neither the RavenDB master nor NATS comes close to saturating its CPU cap here -- scheduling is fast enough (23888 jobs/sec) that the bottleneck sits elsewhere, most likely in how quickly workers can claim and execute jobs once scheduled, the same execution-side coordination overhead discussed on the main comparison page.
Both containers running well under their caps (42% avg CPU for the RavenDB master, 14% avg for NATS) suggests there's real headroom left untested in this round, in two different directions:
-
Higher job volume: this run's 60 scheduling requests stay fixed regardless of total burst size, so a larger burst just means more jobs per request. With neither the database nor NATS anywhere near saturated, scheduling throughput above 23,888 jobs/sec is plausible at a higher volume than the 50,000 tested here -- untested for now, not run as part of this round.
-
More buckets / higher
ParallelismFactor: since both the RavenDB master and NATS ran smoothly with resources to spare, there's likely room to raise bucket count and/orParallelismFactorbeyond this round's settings and push execution throughput higher without either server becoming the bottleneck first.
Neither is confirmed with a run yet -- both are plausible directions for a future benchmark round, not claims backed by data in this one.