Skip to main content

JobMaster + RavenDB

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: 3 CPU / 6 GB -- half the CPU and a third of the memory of every other engine in this comparison. This is a Community Edition licensing limit (RavenDB's free tier caps a node at 3 CPU cores), not a benchmark choice -- see Methodology
  • Worker resources: 2 CPU / 4 GB
  • EC2 instance: m6id.12xlarge (48 vCPU / 192 GB)
  • Reps averaged: 3

Throughput & correctness​

  • Scheduling throughput: 6520 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 call7221726172947674767460

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
Immediate723227234112001213302514038050000

Container resource usage​

Averages/maxes across all reps and all 20 workers.

Containerlimit (CPU/mem)avg CPU%max CPU%avg mem (MB)max mem (MB)
db3 CPU / 6 GB138.9203.73257.13886.8
workers (avg of 20)2 CPU / 4 GB14.226.8728.2746.1