JobMaster + PostgreSQL
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: 50,000
- Requests: 60 x 833 jobs each (all fired in parallel)
- Workers: 20
- DB resources: 6 CPU / 16 GB
- Worker resources: 2 CPU / 4 GB
- EC2 instance:
m6id.16xlarge(64 vCPU / 256 GB) - Reps averaged: 3
Throughput & correctness
-
Scheduling throughput: 6059 jobs/sec (avg of 3 reps)
-
Execution throughput: 356.2 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 | 7582 | 7830 | 8190 | 8253 | 8253 | 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 | 69812 | 69829 | 117425 | 130928 | 140361 | 50000 |
Container resource usage
Averages/maxes across all reps and all 20 workers.
| Container | limit (CPU/mem) | avg CPU% | max CPU% | avg mem (MB) | max mem (MB) |
|---|---|---|---|---|---|
| db | 6 CPU / 16 GB | 207.5 | 382.5 | 2899.1 | 3624.3 |
| workers (avg of 20) | 2 CPU / 4 GB | 13.3 | 18.0 | 276.5 | 284.2 |