JobMaster + MySQL (2x Execution): 4 buckets, 20 concurrent execution slots/worker
Average of 3 repeated runs. See JobMaster vs. Hangfire for how this fits into the full cross-framework comparison, and Benchmark Methodology for the test setup.
- Total burst jobs: 25,000
- Requests: 60 x 416 jobs each (all fired in parallel)
- Workers: 20
- DB resources: 3 CPU / 6 GB
- Worker resources: 0.25 CPU / 0.5 GB
- Reps averaged: 3
Throughput & correctness
- Scheduling throughput: 1274 jobs/sec (avg of 3 reps)
- Execution throughput: 226.3 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 416 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 | 14840 | 14552 | 17956 | 19660 | 19660 | 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 | 64894 | 66369 | 92201 | 102572 | 110464 | 25000 |
Container resource usage
Averages/maxes across all reps and workers.
| Container | limit (CPU/mem) | avg CPU% | max CPU% | avg mem (MB) | max mem (MB) |
|---|---|---|---|---|---|
| db | 3 CPU / 6 GB | 164.7 | 305.9 | 1635.4 | 2145.6 |
| workers (avg of 20) | 0.25 CPU / 0.5 GB | 18.0 | 26.8 | 137.7 | 152.6 |