Benchmark: Kafka builds 6.6x faster on Avrea than GitHub Actions
On GitHub Actions, a no-cache Kafka build takes 5 minutes 44 seconds. On Avrea, the same build, same 2 vCPU spec: 2 minutes 10 seconds without cache, 52 seconds with Gradle's remote cache.
Why Kafka
Apache Kafka is a widely-used JVM project with a big Gradle build: hundreds of modules and a long test suite. The compilation behavior (heavy javac usage, cross-module dependencies, per-module test tasks) is close to what you'd see on other JVM services at this size.
Kafka's Gradle setup uses the Gradle build cache for task outputs. The cache can be local or remote; in CI, only remote caching helps across runs. We benchmarked the remote-cache path.
How we ran the test
We ran ./gradlew assemble on both sides. Same runner (2 vCPU, 7.8 GiB). Temurin 21. Same Kafka commit.
| GitHub Actions | Avrea | |
|---|---|---|
| Runner label | ubuntu-24.04 | avrea-ubuntu-latest-2-vcpu |
| vCPU | 2 | 2 |
| RAM | 7.8Gi | 7.8Gi |
For the cached run, Gradle's remote cache pointed at Avrea's cache backing. On the no-cache run, build caching was disabled entirely. The GitHub Actions side had no remote cache hooked up on either run.
A few runs per config; we kept the typical one.
Results
| GitHub Actions | Avrea | Speedup | |
|---|---|---|---|
| No cache | 5m 44s | 2m 10s | 2.6x |
| With cache | n/a | 52.2s | 6.6x |
Hardware alone buys 2.6x. Turning on Gradle's remote cache against Avrea's cache layer gets the warm number to 52 seconds, for 6.6x total.
Why it's faster
The hardware (the 2.6x)
A no-cache Kafka build spends most of its time in javac and incremental class compilation across modules. CPU-bound work, with real disk pressure from writing intermediate class files.
Avrea's 2 vCPU runner on dedicated hardware pulls the 2.6x on its own. Same mechanics as every other CPU-bound JVM build.
The cache (the 6.6x)
Gradle's remote cache stores task outputs (compiled class files, test results, etc.) keyed by the hash of each task's inputs. On a cached run, if a task's inputs match, Gradle pulls the output and skips the task entirely.
The hit rate is worth a mention: about 23% even on a warm run. Most of Kafka's rebuild work is test compilation. Kafka's per-module test tasks share dependencies that tend to change between runs, so they invalidate more often than a stricter cache setup would. A team running just assemble without tests would see a noticeably higher hit rate.
That's why Kafka's 6.6x is more modest than the 39x on Bazel or the 142x on Next.js. 6.6x is still a real speedup; the ceiling is just lower given how the build is structured.
Other benchmarks in this series
- Bazel (39.7x)
- Linux kernel (68x)
- Ghostty (27x)
- Next.js (142x)
- RisingWave (11.5x)
What Avrea is
Avrea is a label swap, not a platform migration. runs-on: avrea-ubuntu-latest and your Gradle pipeline runs on our hardware.
Every job comes with CPU and memory at step granularity, searchable log history, and SSH into the running VM when you need it. Flaky JVM tests are where the SSH access earns its keep. A test that only fails on the CI box usually needs jstack or a heap dump, which you can only get from the running VM.
