DEV Community

Tosiiko
Tosiiko

Posted on

WeTask v0.1.0-rc.1 vs Redis benchmark report

#python #programming #productivity #automation

Run date: 2026-07-25 (Africa/Kampala)

Outcome

All recorded benchmark cells completed with zero operation errors. Redis was
faster than WeTask on comparable network cache operations and on the controlled
mixed pipeline matrix. WeTask pipeline throughput improved substantially as the
pipeline size increased, reaching a three-trial median of about 402k operations
per second for 1,000-operation pipelines at concurrency 16; Redis reached about
886k operations per second in the same cell.

Queue-ingress numbers are not equivalence claims. WeTask SubmitTask enters its
task lifecycle and the release's fallback handler executes the task. Redis
LPUSH only appends bytes to a non-persistent list. The repository's Celery
probe also measures producer enqueue only, with no worker, acknowledgement,
retry, or result measurement.

Environment

  • Host: MacBook Air, Apple M3, 8 host cores, 16 GiB RAM
  • OS: macOS 15.7.3, Darwin 24.6.0, arm64
  • Docker Desktop: 4.66.1; Docker Engine 29.3.1, Linux arm64
  • Docker allocation: 4 CPUs, 8,573,693,952 bytes RAM
  • WeTask network target: published wetask-io/wetask:v0.1.0-rc.1 (820859d, built 2026-07-11), standalone, consensus disabled
  • WeTask source benchmarks: worktree commit d6131019163f31c94022eafc65cf318ce163ba73
  • Redis: 7.4.9, standalone, save "", appendonly no, no memory limit, noeviction, one I/O thread
  • Container limits: neither container had a per-container CPU or memory limit
  • Clients: Go 1.26.5, go-redis/v9 9.12.1; Python 3.14.4, redis-py 6.4.0, Celery 5.6.3; Node 25.4.0
  • Network: one Go process on the macOS host to both containers over Docker-published loopback TCP ports
  • Execution: workloads were run serially to avoid intentional cross-load

Controlled network cache results

Each unary cell used 1,000 measured operations per worker after 25 unmeasured
warm-up calls per worker. Workers reused one distinct hot key each with a
60-second TTL.

Payload Concurrency Operation WeTask ops/s Redis ops/s Redis/WeTask WeTask p95 Redis p95
64 B 1 SET 1,621 3,532 2.18x 1.38 ms 0.31 ms
64 B 1 GET hit 1,916 3,498 1.83x 1.15 ms 0.31 ms
64 B 16 SET 6,956 20,176 2.90x 4.18 ms 1.54 ms
64 B 16 GET hit 6,412 18,853 2.94x 4.63 ms 1.52 ms
64 B 64 SET 9,581 30,422 3.18x 13.48 ms 3.55 ms
64 B 64 GET hit 9,294 32,345 3.48x 14.23 ms 3.20 ms
1,024 B 1 SET 1,672 3,288 1.97x 1.34 ms 0.34 ms
1,024 B 1 GET hit 1,924 3,444 1.79x 1.18 ms 0.32 ms
1,024 B 16 SET 6,866 18,861 2.75x 4.46 ms 1.61 ms
1,024 B 16 GET hit 6,582 17,761 2.70x 4.91 ms 1.64 ms
1,024 B 64 SET 8,606 23,802 2.77x 15.25 ms 5.39 ms
1,024 B 64 GET hit 6,999 23,397 3.34x 20.21 ms 4.98 ms

These are single recorded unary samples. Redis was consistently faster, but the
exact ratios should not be treated as stable capacity limits.

Controlled mixed pipeline results

Both products executed the same ordered, non-transactional
SET / GET / DELETE mix using 64-byte values. Each worker issued 100 measured
pipelines per cell after 25 warm-up pipelines (five for size 1,000). Values are
the median of three complete trials; all trials had zero errors.

Pipeline operations Concurrency WeTask ops/s Redis ops/s Redis/WeTask WeTask p95/pipeline Redis p95/pipeline
10 1 15,859 32,554 2.05x 1.20 ms 0.33 ms
10 16 74,135 160,198 2.16x 3.75 ms 1.91 ms
100 1 116,655 175,639 1.51x 1.59 ms 1.28 ms
100 16 256,634 727,032 2.83x 13.87 ms 4.33 ms
1,000 1 221,638 434,694 1.96x 6.31 ms 3.55 ms
1,000 16 402,175 886,477 2.20x 87.58 ms 26.22 ms

The repository's independent packaged-client pipeline harness also passed all
six cells with zero errors. Its one-run WeTask range was 15.6k ops/s
(size 10, concurrency 1) through 394.2k ops/s (size 1,000, concurrency 16).

Queue-ingress probes

The controlled Go probe used a printable 64-byte payload, 500 measured submits
per worker, 25 warm-up submits per worker, a fresh WeTask volume, and a flushed
Redis database.

Concurrency WeTask SubmitTask Redis LPUSH WeTask p95 Redis p95
1 334 ops/s 3,340 ops/s 4.03 ms 0.34 ms
16 301 ops/s 19,037 ops/s 66.51 ms 1.83 ms

The documented Celery producer probe submitted 10,000 tasks at 728 tasks/s
sequentially. It used Redis as broker but no Celery worker or result backend.
The documented Redis cache probe completed 30,000 sequential SET/GET/TTL
operations at 2,696 operations/s.

WeTask-only documented benchmark coverage

  • Official five-second Phase 9 baseline: 23 rows, including task, scheduler, cache, cache replication, consensus commit, failover, rolling restart, and node resource snapshots.
  • In-process task submit: 2.05 million ops/s; task completion: 157.9k ops/s.
  • In-process cache SET: 753k ops/s; GET hit: 3.19 million ops/s.
  • Consensus commit: 5.44 ms/op; failover: 258 ms; rolling restart: 976 ms.
  • Fast-cache server path: unary GET 628 ns/op, unary SET 1.56 microseconds/op; pipeline service path 4.74 microseconds for 10 operations, 51.1 microseconds for 100, and 400 microseconds for 1,000.
  • Live release HTTP cache, 10,000 operations each: concurrency 1 produced 1.55k SET, 2.04k GET, and 2.00k DELETE ops/s; concurrency 64 produced 2.74k SET, 3.42k GET, and 4.39k DELETE ops/s.
  • Release task matrix: 12 concurrency/payload/handler-duration cells, with zero errors. Concurrency was 1/16/64, payload was 0/1,024 bytes, and handler delay was 0/50 ms.
  • Documented competitive suite: 14 Go rows and all three required competitor probes passed; no probe was skipped.

Reproducible commands 

WETASK_PHASE9_BENCHTIME=5s WETASK_PHASE9_BENCH_QUIET=1 \
  ./scripts/benchmark-phase9.sh /tmp/wetask-redis-comparison-20260725/phase9-baseline-full

WETASK_BENCH_QUIET=1 go test -run '^$' -bench BenchmarkFastCache \
  -benchmem -benchtime=5s ./internal/network

WETASK_HTTP_BASE=http://127.0.0.1:38081 \
WETASK_LIVE_WORKLOADS=cache WETASK_LIVE_CACHE_OPS=10000 \
WETASK_LIVE_CACHE_CONCURRENCY=64 \
  node scripts/benchmark-phase9-live-http.mjs

go run ./examples/go-client/cache-pipeline-benchmark \
  -address 127.0.0.1:38080 -sizes 10,100,1000 \
  -concurrency 1,16 -iterations 100 -json

WETASK_HTTP_BASE=http://127.0.0.1:38081 \
WETASK_GRPC_ADDRESS=127.0.0.1:38080 \
WETASK_PIPELINE_ITERATIONS=100 WETASK_MATRIX_TASK_OPS=200 \
  ./scripts/benchmark-release-matrix.sh \
  /tmp/wetask-redis-comparison-20260725/release-matrix

PATH=/tmp/wetask-bench-venv/bin:/usr/local/go/bin:/opt/homebrew/bin:/usr/bin:/bin \
WETASK_PHASE9_BENCHTIME=5s WETASK_PHASE9_COMPETITOR_OPS=10000 \
WETASK_PHASE9_REDIS_URL=redis://127.0.0.1:6380/0 \
WETASK_PHASE9_CELERY_BROKER_URL=redis://127.0.0.1:6380/0 \
WETASK_PHASE9_REQUIRE_COMPETITORS=1 \
  ./scripts/benchmark-phase9-competitive.sh \
  /tmp/wetask-redis-comparison-20260725/competitive-documented-full

/tmp/wetask-redis-comparison-20260725/network-compare/network-compare \
  -wetask 127.0.0.1:38080 -redis 127.0.0.1:6380 \
  -unary-iterations 1000 -pipeline-iterations 100 \
  -queue-iterations 500 -warmup 25
Enter fullscreen mode Exit fullscreen mode

Limitations and conclusion

  • In-process Go numbers are implementation baselines and must not be compared directly with network Redis numbers.
  • Redis persistence was disabled. This is appropriate for a cache-path speed baseline but not equivalent to a durable task broker.
  • WeTask used standalone mode with consensus disabled. No clustered Redis, WeTask replication, cross-host latency, TLS/auth, eviction pressure, permanent-node loss, or multi-tenant load was benchmarked.
  • The machine was not lab-isolated, Docker shared four CPUs, and most cells have one recorded sample. Pipeline cells have three trials and report medians.
  • WeTask remains technically functional and error-free in this local run, but Redis has a clear cache/pipeline performance advantage here. These results do not remove the integration blocker: the published WeTask release still needs a supported Python worker/execution bridge before it can replace Celery workers.

Top comments (0)