Performance against Velocity

Rift and Velocity run one after the other against the same synthetic Minecraft backend on the same machine, under the same offered workload. The comparison records proxy CPU, resident memory, latency, throughput and failures. It is a loopback protocol benchmark, not a player capacity estimate.

#Results

Rift used less CPU and memory in every profile. Echo latency ranges overlap, so these runs do not rank the proxies on echo latency. Both proxies completed all 108,288 measured operations with zero failures.

Two outliers are worth noting. One 64-client Rift login trial had a 135.73 ms p99 (135.99 ms maximum) from a single slow 64-login wave. One Velocity 64-client warmup missed 7 of 115,200 scheduled echoes; warmup is excluded from the tables but kept in the raw reports. These measurements cannot tell whether the outliers came from the proxy, the load generator or the host.

Each profile ran three trials per proxy: 2,048 warmup logins, 30 seconds of echo warmup, 20 seconds of measured echoes, then 2,048 measured logins in waves the size of the client count.

#16 concurrent clients

16 clients, 20 echoes/s/client, 1024 payload bytes, 3 trials.

Medians of per-trial values; parentheses show minimum–maximum. Failure counts pool all measured trials.

Raw JSON, gzip compressed.

#64 concurrent clients

64 clients, 20 echoes/s/client, 1024 payload bytes, 3 trials.

Medians of per-trial values; parentheses show minimum–maximum. Failure counts pool all measured trials.

Raw JSON, gzip compressed.

Also published: artifact checksums and settings, process logs and generated configurations and validation evidence.

#Setup

Measured September 30, 2026 on a shared developer desktop, not an isolated lab: Intel Core Ultra 5 125U (14 logical CPUs), 15.1 GiB RAM, Debian kernel 7.2.6+deb14-amd64, Python 3.14.7. No builds or tests ran during measurement.

The worker settings match event-loop threads only; neither process is limited to two CPUs. The Velocity jar is pinned by SHA-256 in tests/velocity.json and downloaded from the PaperMC downloads service. Raw reports record executable hashes, Java release metadata, commands and generated configuration.

Both proxies run the same workload:

• Minecraft Java 1.8.9 (protocol 47), offline login, one backend.
• No player forwarding, encryption, compression, plugins or Lua callbacks.
• Login and packet rate limits disabled. Velocity connection logging, BungeeCord channel handling and bStats are disabled; Rift has no metrics listener.
• The same Python backend and load generator over loopback TCP with TCP_NODELAY and a 1460-byte MSS.
• Each client logs in, receives Join Game, then exchanges plugin messages; every echo is checked against its payload.

Velocity enables compression and login throttling by default; they are disabled here to compare plain forwarding. See the Velocity configuration reference.

#Reproduce

Requires Linux, Python 3.11+, the pinned Rust toolchain and Java 25. Stop other builds and tests before measuring.

cargo build --release --locked
python3 scripts/fetch_velocity.py

RIFT_BENCH_JAVA=/path/to/java25/bin/java
for clients in 16 64; do
  python3 tests/compare_velocity.py \
    --binary target/release/rift \
    --velocity-jar target/velocity/velocity-4.2.0-30.jar \
    --java "$RIFT_BENCH_JAVA" \
    --trials 3 --clients "$clients" --burst-size "$clients" \
    --warmup 30 --duration 20 --rate 20 --payload-bytes 1024 \
    --attempts 2048 --timeout 5 --workers 2 --java-heap-mib 1024 \
    --report "target/comparison-$clients.json" \
    --work-dir "target/comparison-$clients-logs"
  python3 scripts/render_performance.py "target/comparison-$clients.json"
done

fetch_velocity.py verifies the cached jar on every run, and the comparison verifies it again before starting. --work-dir must not exist yet; it keeps every process log and generated configuration.

Request failures are recorded as results, not errors. Add --require-success to exit nonzero on any failed request. Infrastructure or configuration errors abort the run, and the renderer refuses the resulting incomplete report.

CI runs the same comparison with two clients, one trial and one second each of warmup and measurement, and uploads its report and logs. It checks correctness only; its numbers are not performance results.

#Reading the measurements

CPU is proxy user plus system time from /proc over the measured interval. 100% is one logical CPU. The table shows the mean for each trial, not peak. Login bursts are much shorter than the 20-second echo windows, so their CPU figures describe short bursts. Counters advance in 10 ms steps. Backend and load-generator CPU are recorded separately in the raw reports.

Memory is peak sampled RSS in MiB, including JVM native memory. It includes memory retained from startup and warmup, and sampling can miss short spikes.

Latency uses nearest-rank percentiles over successful operations. Echo latency runs from the scheduled send slot to the verified reply, so it includes load-generator dispatch delay; raw reports also record RTT and dispatch delay separately. Login latency runs from TCP connect to Join Game plus one verified echo.

Failures include timeouts, rejected connections, incorrect echoes and missed send slots. Each client has at most one outstanding echo, and a failed session counts all its remaining slots as failures, so offered load never drops. Read CPU alongside throughput and failures: doing less work uses less CPU.

Each trial starts fresh proxy and backend processes, and the proxy order alternates between trials. Treat the results as medians with ranges, not statistically significant rankings.

#Limitations

The fixture covers login, the transition to play and plugin-message forwarding. It does not cover chunk traffic, movement, tick scheduling, configuration phases, signed chat, authentication, encryption, compression, backend switching or plugins, and loopback is not a real network. Fixed-rate tests measure neither maximum throughput nor maximum player count.

The single Python load generator may limit login throughput. JIT, garbage collection, CPU frequency scaling, scheduling and other applications all add variance. Compare only results with matching workload and runtime settings, and test on deployment hardware before making capacity decisions.