JobMaster Benchmark Results
This page backs the recommendations in the Performance Tuning Guide with real, repeatable numbers: JobMaster's scheduling and execution throughput across multiple database providers, run under matched concurrency and matched job volume.
See Benchmark Methodology for how this comparison is set up: fair concurrency matching, resource caps, test hardware, and burst-mode test shape.
SQL Server results (both JobMaster and Hangfire) have been withheld from this page. SQL Server's license terms require Microsoft's prior written approval before publishing benchmark results, which wasn't obtained before this round -- so those numbers aren't included here pending that approval.
This comparison is based on 50k-job bursts, 20 workers, ParallelismFactor 2, 2 CPU / 4 GB worker
containers throughout. Jobs are scheduled the same way a real caller would: real HTTP requests
against the scheduling endpoint, fired in batches, not an in-process/SDK-only microbenchmark. Each
config name in the tables below links to its full detail page. A separate
RavenDB + NATS run, using a different agent-side transport, is documented on
its own page rather than mixed into the tables below.
Results: Scheduling and Execution
Scheduling is how long it took to accept and durably persist the entire burst. Execution is how long it took, once accepted, for jobs to actually complete. Latency figures are mean / p99 across the 3 averaged reps.
| Config | Scheduling throughput/latency | Execution throughput/latency |
|---|---|---|
| JobMaster + RavenDB* | 6520/sec, 7.2s / 7.7s | 356.2/sec, 72.3s / 133.0s |
| JobMaster + PostgreSQL | 6059/sec, 7.6s / 8.3s | 356.2/sec, 69.8s / 130.9s |
| JobMaster + MySQL | 4359/sec, 7.0s / 11.5s | 349.1/sec, 72.8s / 134.4s |
m6id.12xlarge instance -- half the
CPU and a third of the memory of every other config here, which ran 6 CPU / 16 GB on m6id.16xlarge.
This is a licensing limit, not a benchmark choice: RavenDB's free Community Edition caps a node at 3
CPU cores. See Methodology.
RavenDB and PostgreSQL lead on both scheduling and execution (RavenDB with less database CPU/memory than the other two, see footnote above), with MySQL close behind on execution but trailing further on scheduling.
Results: Resource Usage
Averages/maxes across all 3 repeated runs and all 20 workers. Database CPU% figures exceed 100 where the cap is more than 1 whole CPU (up to 600% for the 6-CPU cap, 300% for RavenDB's 3-CPU cap).
| Config | DB avg/max CPU% | DB avg/max mem (MB) | Worker avg/max CPU% | Worker avg/max mem (MB) |
|---|---|---|---|---|
| JobMaster + RavenDB* | 138.9 / 203.7 | 3257.1 / 3886.8 | 14.2 / 26.8 | 728.2 / 746.1 |
| JobMaster + PostgreSQL | 207.5 / 382.5 | 2899.1 / 3624.3 | 13.3 / 18.0 | 276.5 / 284.2 |
| JobMaster + MySQL | 250.9 / 388.7 | 2094.1 / 2672.6 | 19.1 / 28.4 | 239.7 / 250.8 |
Every engine here stays comfortably under its CPU cap. RavenDB's worker memory footprint is visibly higher than either SQL engine's (its client keeps more in memory per connection), worth accounting for if you're tightening worker memory limits.
A different topology: RavenDB + NATS, 23.8k jobs/sec scheduling throughput
Every config above points both master and agent connections at the same database server. JobMaster also supports splitting the agent-side transport onto something else entirely -- for example, NATS instead of RavenDB itself, with RavenDB kept only as the master (job records/audit trail). That config isn't in the tables above since it isn't a fair comparison against them (see Methodology), but its numbers are worth calling out on their own.
Moving the agent transport off RavenDB removes it from the scheduling hot path entirely, and it shows: 23,888 jobs/sec scheduling throughput, 3.7x the fastest single-server config above (RavenDB alone, at 6,520/sec). Execution throughput lands at 327.1/sec, in the same range as the single-server configs -- the gain here is specifically in how fast the burst gets accepted, not in how fast jobs execute once scheduled.
See JobMaster + RavenDB + NATS for the full breakdown, including resource usage and headroom for further tuning.
Takeaways
Scheduling: JobMaster accepts a full 50k-job burst in 7-20s depending on database engine. If your callers mainly need a fast, durable ack that a job was accepted, JobMaster gets out of the way quickly regardless of which supported database backs it.
Correctness: every config here stayed at zero lost, zero duplicated jobs across all 3 averaged reps. JobMaster is designed around at-least-once delivery, not exactly-once, so occasional duplicates remain a possibility under different conditions -- worth weighing if exactly-once delivery matters for your workload, even though none showed up in this round.
Resources: RavenDB led the field despite running with less database CPU/memory than the other two engines here -- worth a re-run at matched resources in a future round.
Topology: if scheduling throughput matters more than a single-server setup can give you, splitting the agent-side transport onto NATS is a real option, not just a theoretical one -- see A different topology above.